Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #3374 > unrolled thread

I wish I understood SSL Certificates better when they ask

Back to article view | Back to comp.os.linux.networking

Contents

  I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-12 23:36 +0000
    Re: I wish I understood SSL Certificates better when they ask Wildman <best_lay@yahoo.com> - 2015-06-12 23:51 +0000
      Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-13 05:21 +0000
    Re: I wish I understood SSL Certificates better when they ask Bit Twister <BitTwister@mouse-potato.com> - 2015-06-13 02:41 +0000
      Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-13 05:42 +0000
        Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-13 23:24 +0000
    Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-13 05:13 +0000
      Re: I wish I understood SSL Certificates better when they ask Richard Kettlewell <rjk@greenend.org.uk> - 2015-06-13 10:01 +0100
      Re: I wish I understood SSL Certificates better when they ask Thomas Richter <thor@math.tu-berlin.de> - 2015-06-13 13:21 +0200
        Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-13 23:21 +0000
      Re: I wish I understood SSL Certificates better when they ask Ian Zimmerman <itz@buug.org> - 2015-06-13 10:46 -0700
      Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-13 23:18 +0000
        Re: I wish I understood SSL Certificates better when they ask "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-06-13 20:30 -0400
          Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-14 02:12 +0000
            Re: I wish I understood SSL Certificates better when they ask "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-06-13 22:43 -0400
        Re: I wish I understood SSL Certificates better when they ask William Unruh <unruh@invalid.ca> - 2015-06-14 00:40 +0000
          Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-14 02:12 +0000
            Re: I wish I understood SSL Certificates better when they ask "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-06-13 22:39 -0400
              Re: I wish I understood SSL Certificates better when they ask William Unruh <unruh@invalid.ca> - 2015-06-14 02:49 +0000
        Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-14 20:05 +0000
          Re: I wish I understood SSL Certificates better when they ask Werner Obermeier <spamfreewob@arcor.de> - 2015-06-14 22:49 +0000
            Re: I wish I understood SSL Certificates better when they ask Richard Kettlewell <rjk@greenend.org.uk> - 2015-06-15 00:31 +0100

Page 1 of 2  [1] 2  Next page →

#3374 — I wish I understood SSL Certificates better when they ask

I wish I understood SSL Certificates better when they ask 
me to accept a certificate from my bank.

http://i.imgur.com/1mizR6B.jpg

How do I make this decision?

Just now, I logged into my Bofa account from my home using 
the same browser and computer and IP address that I normally 
use.

Bofa allowed me to log in, but, when I hit one of the billpay
options, it asked me to download that SSL certificate because 
the previous certificate expired a few days ago.

You'd think that a big bank would fix this in 3 days.
Also, I'm using my normal browser & IP address.
And, the domain appears to be a valid domain.

How do I decide if I should accept this certificate?

PS: I obfuscated the URL just in case it was specific to my
BofA account. Did I need to do that or does the URL not matter?

[toc] | [next] | [standalone]

#3375

On Fri, 12 Jun 2015 23:36:53 +0000, Werner Obermeier wrote:

> I wish I understood SSL Certificates better when they ask me to accept a
> certificate from my bank.
> 
> http://i.imgur.com/1mizR6B.jpg
> 
> How do I make this decision?
> 
> Just now, I logged into my Bofa account from my home using the same
> browser and computer and IP address that I normally use.
> 
> Bofa allowed me to log in, but, when I hit one of the billpay options,
> it asked me to download that SSL certificate because the previous
> certificate expired a few days ago.
> 
> You'd think that a big bank would fix this in 3 days.
> Also, I'm using my normal browser & IP address.
> And, the domain appears to be a valid domain.
> 
> How do I decide if I should accept this certificate?
> 
> PS: I obfuscated the URL just in case it was specific to my BofA
> account. Did I need to do that or does the URL not matter?

I would call the bank and ask them.

-- 
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!

[toc] | [prev] | [next] | [standalone]

#3378

Wildman <best_lay@yahoo.com> wrote in FfKex.1126627$dT.474781@fx35.am4:

> I would call the bank and ask them.

You'll notice that the tabs in the screenshot are open to 3 tabs:
http://i.imgur.com/1mizR6B.jpg

1. online banking
2. certificate services
3. contacting Bank of America

My first call got someone who said to just accept whatever the bank
web site gives me. When I protested, they said to call the online
banking instead of customer service.

My second call went to online banking, who took down my information 
but said they had never heard of the problem before. 

My third call went to the supervisor of that person who, when I asked
if they knew what SSL meant, said they did not (so I realized I was 
not going to get a straight answer from her on that call).

At that point, I had posted my question to you.

Luckily, I received a call back from the third person (the online
banking support supervisor) who had checked with their third-party
IT people who confirmed there was some kind of unspecified problem
that they were working on.

Hours later, they fixed it (I just logged in). 

I'm not sure what happened though, as I briefly saw a URL for something
like sso.bankofamerica.com (or something like that) and then it just
went to online banking (without asking me any questions).

So, what was that brief intermediary URL doing?

[toc] | [prev] | [next] | [standalone]

#3376

On Fri, 12 Jun 2015 23:36:53 +0000 (UTC), Werner Obermeier wrote:
> I wish I understood SSL Certificates better when they ask 
> me to accept a certificate from my bank.

I wish you knew how to cross post.  :-(

Had not somebody not replied to you post I never would have seen it.
Linux question and any Windows news group means the post is not seen
by me.

> How do I make this decision?
>
> Just now, I logged into my Bofa account from my home using 
> the same browser and computer and IP address that I normally 
> use.

Well, at least you know any malware in your setup is the same.

> Bofa allowed me to log in, but, when I hit one of the billpay
> options, it asked me to download that SSL certificate because 
> the previous certificate expired a few days ago.

I would abort.

> You'd think that a big bank would fix this in 3 days.

You would think the customer's would call and ask about the certificate.
Did you call the security department. I would.

I used to use BOA. One day I clicked View Source and saw the web page
calling an external third party ad server. Next day drove over to the bank and
closed my account. That was when criminals were cracking into ad
servers fairly often.

> Also, I'm using my normal browser & IP address.
> And, the domain appears to be a valid domain.

Which tells us the problem can be on your side just as easily on theirs.

> How do I decide if I should accept this certificate?

Call the bank security phone number.

> PS: I obfuscated the URL just in case it was specific to my
> BofA account. Did I need to do that or does the URL not matter?

Usually all we would need is up to the first / after .com. So,

$ nslookup sso-fi.bankofamarica.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   sso-fi.bankofamarica.com
Address: 69.162.80.52

$ whois 69.162.80.52

 <snip>

OrgName:        Limestone Networks, Inc.
OrgId:          LIMES-2
Address:        400 S. Akard Street
Address:        Suite 200
City:           Dallas
StateProv:      TX
PostalCode:     75202
Country:        US
RegDate:        2007-12-04

  <snip>

Off hand, does not look good enough for me.  So,

$ whois bankofamarica.com

   Domain Name: BANKOFAMARICA.COM
   Registrar: ENOM, INC.
   Sponsoring Registrar IANA ID: 48
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com
   Name Server: NS1.HASTYDNS.COM
   Name Server: NS2.HASTYDNS.COM
Registry Registrant ID: 
Registrant Name: WHOIS AGENT
Registrant Organization: WHOIS PRIVACY PROTECTION SERVICE, INC.
Registrant Street: PO BOX 639
Registrant Street: C/O BANKOFAMARICA.COM
Registrant City: KIRKLAND
Registrant State/Province: WA
Registrant Postal Code: 98083
Registrant Country: US
Registrant Phone: +1.4252740657
Registrant Phone Ext: 901
Registrant Fax: +1.4259744730


Yeah, that looks a bit better. Again, I would call the banks's
security team.

Couple of places where the problem is on your system could be the
router, your dns resolver, in memory malware, malware installed on the
system or the browser's dns cache/bookmarks or you mistype the BOA url.

My bank suggests you always exit the browser before attempting to log
into the web site. That way the browser's dns cache will not have
poisoned by some infected web site you surfed before doing bank work.
If some malware modified your browser bookmark for BOA, you are screwed.

I hope your bank have a usage alarm feature. I have set alarms on my
check/savings account to send me an email if more than ten cents is
paid out. I have a hourly cron job checking my all email accounts for any
messages. 

If you were running Intrusion Detection Software, you would have a
chance of knowing you have malware installed on the drive. Some examples:
unhide, aide, osiris, ossec-hids, samhain, tripwire, snare, integrit, rkhunter
 
Personally I use AIDE, Rkhunter, and unhide.

The other two failure points are the router and your pc dns resolver.

If you were to read http://www.catb.org/~esr/faqs/smart-questions.html
you might notice that you should provide some information about your setup.

You know, hardware, OS, release, desktop, .....

That information can help subject matter experts provide you with
exact commands and information on where/what to look for to solve your
problem.

In my stupid opinion, you need to know that your PC has the correct
dns servers set, and if the router has the correct dns servers set by
your ISP.

My effort to avoid the dns/memory/cache/typing problems involve separate
linux accounts for surfing, bank, credit card.

When I log into my linux bank account, it verifies the ip addresses
that I know my bank uses. It then launches "firefox index.html".
That page has bank contact information and links to the bank's web
page and the bank's login url.

That keeps me from mis-typing any url and having a poisoned cache.
When I log out of the linux account, it deletes everything and tars in
a pristine copy of everything. 

To bypass getting invalid dns servers from my ISP on the pc, and
avoiding any router crack which uses the criminal's dns servers, I run
my own dns server (named) on the PC. 

[toc] | [prev] | [next] | [standalone]

#3379

Bit Twister <BitTwister@mouse-potato.com> wrote in
slrnmnn663.o9l.BitTwister@wb.home.test:

> I wish you knew how to cross post.  :-(

I'm not sure what I did wrong, as I "think" I know how to 
crosspost. I just didn't set any followup newsgroup.

Is that what you mean by not knowing how to crosspost?
Did you want me to set a followup newsgroup?

> I would abort.

I did abort.

But I don't understand why it took the bank 3 days to realize
their certificate expired, and, more to my point, how the *new*
updated certificate is supposed to get into my browser.

> You would think the customer's would call and ask about the certificate.
> Did you call the security department. I would.

After my third call to BofA to no avail, I had posted the question here.
(See details in my prior post.)

> $ nslookup sso-fi.bankofamarica.com

You have a typo there.
It's "america" (not amarica).

$ nslookup sso-fi.bankofamarica.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   sso-fi.bankofamarica.com
Address: 69.162.80.52

$ ^amarica^america
nslookup sso-fi.bankofamerica.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
sso-fi.bankofamerica.com        canonical name = saml-bac.onefiserv.com.
saml-bac.onefiserv.com  canonical name = saml-bac.gslb.onefiserv.com.
Name:   saml-bac.gslb.onefiserv.com
Address: 208.235.248.157

> $ whois bankofamarica.com

Again, it's "america" (not amarica).

$ whois bankofamerica.com
   Domain Name: BANKOFAMERICA.COM
   Registrar: CSC CORPORATE DOMAINS, INC.
  
> Couple of places where the problem is on your system could be the
> router, your dns resolver, in memory malware, malware installed on the
> system or the browser's dns cache/bookmarks or you mistype the BOA url.

I was already logged into the BofA account, so, it couldn't have been
a typo on my part. It failed when I hit the billpay button.

In the end, their certificate had expired. But, what I don't understand
is how I'm supposed to know what to do based on the information presented
to me of the certificate having expired 3 days ago.

Also, how does the *new* certificate get to me?

I didn't explicitly load it (but I did see something briefly happening
in the background when I successfully logged in a few minutes ago).

What happened in the background?
Did BofA somehow transfer the new certificate to me under the covers?

> My bank suggests you always exit the browser before attempting to log
> into the web site. That way the browser's dns cache will not have
> poisoned by some infected web site you surfed before doing bank work.
> If some malware modified your browser bookmark for BOA, you are screwed.

My browser is set to dump everything upon each invocation, so, the
chances of that being the problem is slim (but it's a good suggestion).

> Personally I use AIDE, Rkhunter, and unhide.

$ unhide
The program 'unhide' is currently not installed. 
You can install it by typing:
sudo apt-get install unhide

$ aide
The program 'aide' can be found in the following packages:
 * aide
 * aide-dynamic
 * aide-xen
Try: sudo apt-get install <selected package>

$ rkkhunter
No command 'rkkhunter' found, did you mean:
 Command 'rkhunter' from package 'rkhunter' (universe)
rkkhunter: command not found

I'll look them up and decide if I want to install them.
Thank you for the suggestions.

> The other two failure points are the router and your pc dns resolver.

I don't see how the router is involved other than it has the DNS setup.

Both my primary and secondary DNS servers are typical:
Primary DNS server = 8.8.8.8 
Secondary DNS server = 8.8.4.4

I'm not sure how to test that this is truly the case though, but, 
that's what I had set up in my home broadband router long ago.

[toc] | [prev] | [next] | [standalone]

#3385

Peter Pearson <pkpearson@nowhere.invalid> wrote in
cu36tnF9popU1@mid.individual.net:

> Which just leads to the question of how your "root-cert" database
> gets maintained. 

I think the entire concept of the "root" certificate is what eludes me.

Let's assume the BofA gave me a new certificate yesterday.
How did my browser validate with a "root" certificate that this was legit?

[toc] | [prev] | [next] | [standalone]

#3377

Mike Easter <MikeE@ster.invalid> wrote in
cu19isFqd6jU1@mid.individual.net:

> Yes they should; however, it is not an uncommon oversight.  It might not 
> even be BoA's fault but that of the CA.

I just tried and they fixed it (a few hours after I had reported it to them).

What I don't get still, is what happened, or, more importantly, what 
*should* have happened when BofA updated its "certificates"?

I presume the certificating authority hands them a new certificate.

But, how does that just-today-updated certificate get back to my browser?

[toc] | [prev] | [next] | [standalone]

#3380

Werner Obermeier <spamfreewob@arcor.de> writes:
> Mike Easter <MikeE@ster.invalid> wrote in
>> Yes they should; however, it is not an uncommon oversight.  It might
>> not even be BoA's fault but that of the CA.
>
> I just tried and they fixed it (a few hours after I had reported it to them).
>
> What I don't get still, is what happened, or, more importantly, what 
> *should* have happened when BofA updated its "certificates"?
>
> I presume the certificating authority hands them a new certificate.
>
> But, how does that just-today-updated certificate get back to my browser?

The web server sends it to your browser as part of the connection setup.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#3381

Am 13.06.2015 um 07:13 schrieb Werner Obermeier:

> What I don't get still, is what happened, or, more importantly, what
> *should* have happened when BofA updated its "certificates"?
>
> I presume the certificating authority hands them a new certificate.
>
> But, how does that just-today-updated certificate get back to my browser?

By your browser, of course. It again checks the certificate against the 
chain of trust, i.e. it checks who issued the certificate, and validates 
that this is certified against one of the root certificates that are 
installed on your Os or browser. So for example, if our university sets 
up a new web server, we obtain a new certificate from the DFN (German 
Research network) which is again certified against the Telekom (German 
phone company), and the Telekom root cert comes with the Mozilla 
browser. So the browser trusts our cert because it can check that it 
comes from the DFN, and Telekom trusts the DFN, and the browser trusts 
Telekom because that's a cert that came with the browser.

For that to work, of course, the DFN has to enforce certain policies 
when handing out certs, namely that they know who is the issuer and can 
validate the correctness, and the Telekom has to enforce certain 
policies to enforce that the DFN only hands out their certs under proper 
policies.

Unfortunately, some certificate authorities did not enforce policies 
correctly and handed out certs for URLs like www.google.com, allowing to 
sign traffic as if it would come from google, for example. Such root 
certs are then blacklisted and removed from browsers.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#3384

Thomas Richter <thor@math.tu-berlin.de> wrote in
mlh3ol$qs1$1@news2.informatik.uni-stuttgart.de:

> By your browser, of course. It again checks the certificate against the 
> chain of trust, i.e. it checks who issued the certificate, and validates 
> that this is certified against one of the root certificates that are 
> installed on your Os or browser.

I guess the part that eludes me is how these root certificates *get* on
my system.

Did "I" put the "root certificates" there? (somehow?)
Did the operating system ISO put them there? 
Did the browser installation pout them there?

How would I find them on my system?
And, how do I make sure nobody messes with them without me knowing it?

[toc] | [prev] | [next] | [standalone]

#3382

On 2015-06-13 05:13 +0000, Werner Obermeier wrote:

Werner> But, how does that just-today-updated certificate get back to my
Werner> browser?

The browser doesn't contain a copy of every site's certificate.  If it
did, it would be impossible to browse random https:// URLs without
endless warnings.

Instead, the browser (or more likely the SSL library it is linked with)
checks that the certificate presented by the site is signed by the CA.
In the simplest case, where the signing CA is a root CA, the CA
certificate _is_ stored locally.  There are only a few dozens of those,
and they are typically distributed together with the browser software.

A more complex case is when the signing CA is an intermediate CA.  I
won't pretend I understand this situation completely, but I think in
this case the site must send the entire chain of signing CA certificates
up to the root, and the browser checks the validity of signatures in
each step of the chain.

hth,

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

[toc] | [prev] | [next] | [standalone]

#3383

Mike Easter <MikeE@ster.invalid> wrote in cu1v5kFepeU1@mid.individual.net:

> https://www.us-cert.gov/ncas/tips/ST05-010  Understanding Web Site 
> Certificates

Thanks for that tip.

That site gave a quick overview, which cleared up some things, but, 
it still didn't even mention HOW my browser knows to trust that a 
particular CA signed the BofA certificate.

How does "my" browser know to trust any particular signing authority?

[toc] | [prev] | [next] | [standalone]

#3386

On Sat, 13 Jun 2015 19:18:40 -0400, Werner Obermeier <spamfreewob@arcor.de> wrote:

> How does "my" browser know to trust any particular signing authority?

The distribution provides a list of trusted root certificates, usually
based on what mozilla considers trusted. In Mageia linux, the package
is called rootcerts.

The files are in subdirectories of /etc/ssl and /etc/pki.

The website provides all certificates in the signing chain, except for
the root certificate.

Additional root certificates can be installed in the user's configuration
directory for a particular browser.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#3388

"David W. Hodgins" <dwhodgins@nomail.afraid.org> wrote in
op.xz62c32fa3w0dxdave@hodgins.homeip.net:

> The files are in subdirectories of /etc/ssl and /etc/pki.

I seem to have the following files:

/etc/ssl/openssl.cnf
-rw-r--r-- 1 root root 10835 Jul 15  2013 openssl.cnf
/etc/ssl/certs/{tons of "verisign" files}
/etc/ssl/private/ssl-cert-snakeoil.key (only this one file)

/etc/pki/nssdb/
-rw-r--r-- 1 root root  9216 Feb 19 05:33 cert9.db
-rw-r--r-- 1 root root 11264 Feb 19 05:33 key4.db
-rw-r--r-- 1 root root   449 Feb 19 05:33 pkcs11.txt
-rw-r--r-- 1 root root 16384 Feb 19 05:33 secmod.db

Does that give you any insight into what I have?

[toc] | [prev] | [next] | [standalone]

#3390

On Sat, 13 Jun 2015 22:12:12 -0400, Werner Obermeier <spamfreewob@arcor.de> wrote:

> Does that give you any insight into what I have?

That's pretty much the same as what I have. If you get a certificate that
fails to verify, check to see if it's only because of the it having
expired. If that is the case, don't worry about it, though it would be
a good idea to notify the web site maintainer. It's easy to forget to
renew a certificate.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#3387

On 2015-06-13, Werner Obermeier <spamfreewob@arcor.de> wrote:
> Mike Easter <MikeE@ster.invalid> wrote in cu1v5kFepeU1@mid.individual.net:
>
>> https://www.us-cert.gov/ncas/tips/ST05-010  Understanding Web Site 
>> Certificates
>
> Thanks for that tip.
>
> That site gave a quick overview, which cleared up some things, but, 
> it still didn't even mention HOW my browser knows to trust that a 
> particular CA signed the BofA certificate.
>
> How does "my" browser know to trust any particular signing authority?

Yes. Browsers come with a list of high level signing authorities that
are supposed to be trusted. 

>

[toc] | [prev] | [next] | [standalone]

#3389

William Unruh <unruh@invalid.ca> wrote in mliihg$40a$1@dont-email.me:

> Yes. Browsers come with a list of high level signing authorities that
> are supposed to be trusted.

Are their root certificates stored in the browser installation directory
or in the root hierarchy?

[toc] | [prev] | [next] | [standalone]

#3391

On Sat, 13 Jun 2015 22:12:51 -0400, Werner Obermeier <spamfreewob@arcor.de> wrote:

> William Unruh <unruh@invalid.ca> wrote in mliihg$40a$1@dont-email.me:
>
>> Yes. Browsers come with a list of high level signing authorities that
>> are supposed to be trusted.
>
> Are their root certificates stored in the browser installation directory
> or in the root hierarchy?

Either in the /etc files, or in the browser config files. For example,
on my system, firefox uses
/home/dave/.mozilla/firefox/kh7grkug.default/cert8.db
for root certificates I've approved, that are not in the /etc directories.

The kh7grkug is a random string generated the first time firefox is
run, so it will be different on your system.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [next] | [standalone]

#3392

On 2015-06-14, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Sat, 13 Jun 2015 22:12:51 -0400, Werner Obermeier <spamfreewob@arcor.de> wrote:
>
>> William Unruh <unruh@invalid.ca> wrote in mliihg$40a$1@dont-email.me:
>>
>>> Yes. Browsers come with a list of high level signing authorities that
>>> are supposed to be trusted.
>>
>> Are their root certificates stored in the browser installation directory
>> or in the root hierarchy?
>
> Either in the /etc files, or in the browser config files. For example,
> on my system, firefox uses
> /home/dave/.mozilla/firefox/kh7grkug.default/cert8.db
> for root certificates I've approved, that are not in the /etc directories.
>
> The kh7grkug is a random string generated the first time firefox is
> run, so it will be different on your system.

In chrome look at chrome://settings/certificates to see what chrome sees
as the authorities.

[toc] | [prev] | [next] | [standalone]

#3393

Richard Kettlewell <rjk@greenend.org.uk> wrote in
wwvh9qa42jw.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid:

> Yes, in the sense that attackers do modify the list of root CAs, given
> the opportunity.  For example:
> https://en.wikipedia.org/wiki/Superfish#Lenovo_security_incident

Apparently, in 2015, the US government advised uninstalling that software 
that came bundled with Lenovo products because of a root certificate 
security issue.

"The installation included a universal self-signed certificate authority; 
the certificate authority allows a man-in-the-middle attack to introduce 
ads even on encrypted pages. The certificate authority had the same 
private key across laptops; this allows third-party eavesdroppers to 
intercept or modify HTTPS secure communications without triggering 
browser warnings by either extracting the private key or using a self-
signed certificate.[4][7][19][20] On February 20, 2015, Microsoft 
released an update for Windows Defender which removes Superfish"

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.networking

csiph-web