Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
I wish I understood SSL Certificates better when they ask
140 views
Skip to first unread message
Werner Obermeier
Jun 12, 2015, 7:36:54 PM6/12/15
to
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?
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?
Mike Easter
Jun 12, 2015, 7:50:54 PM6/12/15
to
Posted to a.o.l only
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?
I would look at the bankofamerica.com domain carefully for reassurance
that I was at the correct address, which you are.
> 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.
Yes they should; however, it is not an uncommon oversight. It might not
even be BoA's fault but that of the CA.
> Also, I'm using my normal browser & IP address.
> And, the domain appears to be a valid domain.
Correct.
> How do I decide if I should accept this certificate?
On that basis. You/We know that the bankofamerica.com domain is where
you want to be and there is no 'typo' in there.
> 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?
In case the URL had anything to do with your account, you might as well
obfuscate that part. That part isn't important to discuss the issue here.
Not every question about a certificate problem is going to have the same
answer.
--
Mike Easter
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?
that I was at the correct address, which you are.
> 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.
even be BoA's fault but that of the CA.
> 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?
you want to be and there is no 'typo' in there.
> 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?
obfuscate that part. That part isn't important to discuss the issue here.
Not every question about a certificate problem is going to have the same
answer.
--
Mike Easter
Wildman
Jun 12, 2015, 7:51:03 PM6/12/15
to
--
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!
Bit Twister
Jun 12, 2015, 10:43:17 PM6/12/15
to
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. :-(
> I wish I understood SSL Certificates better when they ask
> me to accept a certificate from my bank.
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.
> 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.
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.
> 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?
$ 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.
Werner Obermeier
Jun 13, 2015, 1:13:21 AM6/13/15
to
Mike Easter <Mi...@ster.invalid> wrote in
cu19is...@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?
cu19is...@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.
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?
Werner Obermeier
Jun 13, 2015, 1:21:15 AM6/13/15
to
Wildman <best...@yahoo.com> wrote in FfKex.1126627$dT.4...@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?
> I would call the bank and ask them.
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?
Werner Obermeier
Jun 13, 2015, 1:42:44 AM6/13/15
to
Bit Twister <BitTw...@mouse-potato.com> wrote in
slrnmnn663.o...@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
$ ^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.
slrnmnn663.o...@wb.home.test:
> I wish you knew how to cross post. :-(
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.
(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
$ ^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.
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.
chances of that being the problem is slim (but it's a good suggestion).
> Personally I use AIDE, Rkhunter, and 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.
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.
Mike Easter
Jun 13, 2015, 1:59:18 AM6/13/15
to
Werner Obermeier wrote:
> I presume the certificating authority hands them a new certificate.
>
> But, how does that just-today-updated certificate get back to my browser?
The new certificate has a good date on it.
> I presume the certificating authority hands them a new certificate.
>
> But, how does that just-today-updated certificate get back to my browser?
https://www.us-cert.gov/ncas/tips/ST05-010 Understanding Web Site
Certificates
--
Mike Easter
Andy Burns
Jun 13, 2015, 2:18:41 AM6/13/15
to
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?
An SSL certificate doesn't become less secure the minute it expires
> 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?
(though it can cause confusion to the end user) but it's a huge warning
that says
"This bank's internet security policy is *NOT* good enough"
Leave them.
Richard Kettlewell
Jun 13, 2015, 5:01:11 AM6/13/15
to
>> 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.
>> 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?
--
http://www.greenend.org.uk/rjk/
Richard Kettlewell
Jun 13, 2015, 5:03:47 AM6/13/15
to
Mike Easter <Mi...@ster.invalid> writes:
are communicating with (in this instance) Bank of America simply by
looking at a domain name, IP address or web page content.
--
http://www.greenend.org.uk/rjk/
> Werner Obermeier wrote:
>> How do I decide if I should accept this certificate?
>
> On that basis. You/We know that the bankofamerica.com domain is where
> you want to be and there is no 'typo' in there.
Err, no. The whole point of TLS is that you cannot be certain that you
>> How do I decide if I should accept this certificate?
>
> On that basis. You/We know that the bankofamerica.com domain is where
> you want to be and there is no 'typo' in there.
are communicating with (in this instance) Bank of America simply by
looking at a domain name, IP address or web page content.
--
http://www.greenend.org.uk/rjk/
Thomas Richter
Jun 13, 2015, 7:21:58 AM6/13/15
to
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
> 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?
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
Peter Pearson
Jun 13, 2015, 1:17:45 PM6/13/15
to
On Sat, 13 Jun 2015 05:42:43 +0000 (UTC), Werner Obermeier wrote:
[snip]
the server sends the new certificate, including a signature of the
new certificate by some certificate authority (CA). If that CA isn't
a generally recognized top-level CA, the server also sends *another*
certificate certifying that CA's public key, signed by a higher-level
CA, . . . hoping ultimately to end up with a signature by a CA whose
public key appears in the root-certificate database on your computer.
Which just leads to the question of how your "root-cert" database
gets maintained. I don't know, but I suspect it gets installed along
with your browser. Your browser will probably allow you to inspect it
and edit it, which you will probably find very interesting, because
in my experience it includes many third-world governmental authorities
whose certification of the security of your connection to your bank
you would not find comforting at all.
(Think about it: If you were logging into bankofamerica.com, and you
happened to look at the certificate chain (Security / View Certificate /
Details) and saw that it was rooted in the certificate of the
Lower Slobbovian Post Office, would you trust that connection?)
--
To email me, substitute nowhere->runbox, invalid->com.
[snip]
>
> Also, how does the *new* certificate get to me?
While your browser is negotiating the secure session with the server,
> Also, how does the *new* certificate get to me?
the server sends the new certificate, including a signature of the
new certificate by some certificate authority (CA). If that CA isn't
a generally recognized top-level CA, the server also sends *another*
certificate certifying that CA's public key, signed by a higher-level
CA, . . . hoping ultimately to end up with a signature by a CA whose
public key appears in the root-certificate database on your computer.
Which just leads to the question of how your "root-cert" database
gets maintained. I don't know, but I suspect it gets installed along
with your browser. Your browser will probably allow you to inspect it
and edit it, which you will probably find very interesting, because
in my experience it includes many third-world governmental authorities
whose certification of the security of your connection to your bank
you would not find comforting at all.
(Think about it: If you were logging into bankofamerica.com, and you
happened to look at the certificate chain (Security / View Certificate /
Details) and saw that it was rooted in the certificate of the
Lower Slobbovian Post Office, would you trust that connection?)
--
To email me, substitute nowhere->runbox, invalid->com.
Werner Obermeier
Jun 13, 2015, 7:18:34 PM6/13/15
to
Andy Burns <usenet....@adslpipe.co.uk> wrote in
4OGdna7i5cSrVubI...@brightview.co.uk:
> An SSL certificate doesn't become less secure the minute it expires
Does that mean that the certificate I was presented with was
valid all along?
For example, could I have paid my bill just as securily as I did
hours later (after the BofA IT team fixed the problem)?
If yes, that means that I should have said "yes" to the challenge.
Is that correct?
4OGdna7i5cSrVubI...@brightview.co.uk:
> An SSL certificate doesn't become less secure the minute it expires
valid all along?
For example, could I have paid my bill just as securily as I did
hours later (after the BofA IT team fixed the problem)?
If yes, that means that I should have said "yes" to the challenge.
Is that correct?
Werner Obermeier
Jun 13, 2015, 7:18:41 PM6/13/15
to
Mike Easter <Mi...@ster.invalid> wrote in cu1v5k...@mid.individual.net:
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?
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?
Werner Obermeier
Jun 13, 2015, 7:21:35 PM6/13/15
to
Thomas Richter <th...@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?
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.
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?
Werner Obermeier
Jun 13, 2015, 7:24:05 PM6/13/15
to
Peter Pearson <pkpe...@nowhere.invalid> wrote in
cu36tn...@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?
cu36tn...@mid.individual.net:
> Which just leads to the question of how your "root-cert" database
> gets maintained.
Let's assume the BofA gave me a new certificate yesterday.
How did my browser validate with a "root" certificate that this was legit?
Boscoe
Jun 13, 2015, 8:31:24 PM6/13/15
to
On 14/06/2015 12:18 AM, Werner Obermeier wrote:
> Andy Burns <usenet....@adslpipe.co.uk> wrote in
> 4OGdna7i5cSrVubI...@brightview.co.uk:
>
>> An SSL certificate doesn't become less secure the minute it expires
>
> Does that mean that the certificate I was presented with was
> valid all along?
>
> For example, could I have paid my bill just as securily as I did
> hours later (after the BofA IT team fixed the problem)?
>
Generally, you should be concerned if it appears on a trusted or secure
> Andy Burns <usenet....@adslpipe.co.uk> wrote in
> 4OGdna7i5cSrVubI...@brightview.co.uk:
>
>> An SSL certificate doesn't become less secure the minute it expires
>
> Does that mean that the certificate I was presented with was
> valid all along?
>
> For example, could I have paid my bill just as securily as I did
> hours later (after the BofA IT team fixed the problem)?
>
site where you enter personal or private information, and it could be a
sign that the site is unsafe.
To be on the safe side, in Firefox, install a free add-on called WOT
(Web Of Trust) which displays a coloured traffic light icon next to
search engine returns and on displayed pages.
<https://addons.mozilla.org/en-us/firefox/addon/wot-safe-browsing-tool/>
David W. Hodgins
Jun 13, 2015, 8:32:36 PM6/13/15
to
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.)
David W. Hodgins
Jun 13, 2015, 8:32:36 PM6/13/15
to
On Sat, 13 Jun 2015 19:18:40 -0400, Werner Obermeier <spamf...@arcor.de> wrote:
> How does "my" browser know to trust any particular signing authority?
The distribution provides a list of trusted root certificates, usually
> How does "my" browser know to trust any particular signing authority?
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.
William Unruh
Jun 13, 2015, 8:41:34 PM6/13/15
to
are supposed to be trusted.
>
Werner Obermeier
Jun 13, 2015, 10:12:13 PM6/13/15
to
"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in
op.xz62c32...@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?
op.xz62c32...@hodgins.homeip.net:
> The files are in subdirectories of /etc/ssl and /etc/pki.
/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?
Werner Obermeier
Jun 13, 2015, 10:12:52 PM6/13/15
to
William Unruh <un...@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?
> Yes. Browsers come with a list of high level signing authorities that
> are supposed to be trusted.
or in the root hierarchy?
David W. Hodgins
Jun 13, 2015, 10:43:49 PM6/13/15
to
On Sat, 13 Jun 2015 22:12:12 -0400, Werner Obermeier <spamf...@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
> Does that give you any insight into what I have?
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.
David W. Hodgins
Jun 13, 2015, 10:43:50 PM6/13/15
to
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.
William Unruh
Jun 13, 2015, 10:50:40 PM6/13/15
to
On 2015-06-14, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
> On Sat, 13 Jun 2015 22:12:51 -0400, Werner Obermeier <spamf...@arcor.de> wrote:
>
>> William Unruh <un...@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
> On Sat, 13 Jun 2015 22:12:51 -0400, Werner Obermeier <spamf...@arcor.de> wrote:
>
>> William Unruh <un...@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.
as the authorities.
Mike Easter
Jun 14, 2015, 12:54:13 PM6/14/15
to
Werner Obermeier wrote:
> Mike Easter
https://wiki.mozilla.org/CA:IncludedCAs This is a list of CA
certificates that are distributed with Mozilla software products. You
can view the source file with all of the included root certificates.
https://support.mozilla.org/en-US/kb/secure-website-certificate When
you visit a secure website, Firefox will validate the website’s
certificate by checking that the certificate that signed it is valid,
and checking that the certificate that signed the parent certificate is
valid and so forth up to a root certificate that is known to be valid.
This chain of certificates is called the Certificate Hierarchy.
You can view your certificates; the linux firefox route is:
Edit/ Preferences/ Advanced/ Certificates/ View certificates
--
Mike Easter
> Mike Easter
> How does "my" browser know to trust any particular signing authority?
It comes with your Firefox browser and you can modify it.
https://wiki.mozilla.org/CA:IncludedCAs This is a list of CA
certificates that are distributed with Mozilla software products. You
can view the source file with all of the included root certificates.
https://support.mozilla.org/en-US/kb/secure-website-certificate When
you visit a secure website, Firefox will validate the website’s
certificate by checking that the certificate that signed it is valid,
and checking that the certificate that signed the parent certificate is
valid and so forth up to a root certificate that is known to be valid.
This chain of certificates is called the Certificate Hierarchy.
You can view your certificates; the linux firefox route is:
Edit/ Preferences/ Advanced/ Certificates/ View certificates
--
Mike Easter
Werner Obermeier
Jun 14, 2015, 1:03:17 PM6/14/15
to
Mike Easter <Mi...@ster.invalid> wrote in
cu5pti...@mid.individual.net:
> It comes with your Firefox browser and you can modify it.
If they're stored on my machine (either by the browser or the OS),
then, anyone can put a malicious one there (since home machines just
can't be secured, period - when even government machines can't be
secured with huge IT departments protecting them).
So, isn't that an extremely weak link in the chain?
John Hasler
Jun 14, 2015, 1:16:58 PM6/14/15
to
Werner Obermeier writes:
> If they're stored on my machine (either by the browser or the OS),
> then, anyone can put a malicious one there (since home machines just
> can't be secured, period...
> If they're stored on my machine (either by the browser or the OS),
> then, anyone can put a malicious one there (since home machines just
Yes they can (though they usually aren't).
> ...- when even government machines can't be secured with huge IT
> departments protecting them).
Large networks operated by large institutions are *extremely* hard to
secure, mostly because they have thousands of careless and/or
incompetent users.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Richard Kettlewell
Jun 14, 2015, 1:34:12 PM6/14/15
to
Werner Obermeier <spamf...@arcor.de> writes:
No, in the sense that it’s no weaker than any other part of your
computer. The same attacker might instead modify your browser or OS,
rendering all other security measures irrelevant.
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
--
http://www.greenend.org.uk/rjk/
> Mike Easter <Mi...@ster.invalid> wrote:
>> It comes with your Firefox browser and you can modify it.
>
> This is what scares me about the so-called 'root' certificates.
>
> If they're stored on my machine (either by the browser or the OS),
> then, anyone can put a malicious one there (since home machines just
> can't be secured, period - when even government machines can't be
> secured with huge IT departments protecting them).
>
> So, isn't that an extremely weak link in the chain?
Yes and no.
>> It comes with your Firefox browser and you can modify it.
>
> This is what scares me about the so-called 'root' certificates.
>
> If they're stored on my machine (either by the browser or the OS),
> then, anyone can put a malicious one there (since home machines just
> can't be secured, period - when even government machines can't be
> secured with huge IT departments protecting them).
>
> So, isn't that an extremely weak link in the chain?
No, in the sense that it’s no weaker than any other part of your
computer. The same attacker might instead modify your browser or OS,
rendering all other security measures irrelevant.
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
--
http://www.greenend.org.uk/rjk/
Werner Obermeier
Jun 14, 2015, 4:05:32 PM6/14/15
to
Richard Kettlewell <r...@greenend.org.uk> wrote in
wwvh9qa...@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"
wwvh9qa...@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
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"
Werner Obermeier
Jun 14, 2015, 6:49:59 PM6/14/15
to
Werner Obermeier <spamf...@arcor.de> wrote in mlkmq9$baf$1...@solani.org:
> Apparently, in 2015, the US government advised uninstalling that
> software that came bundled with Lenovo products because of a root
> certificate security issue.
I wasn't sure, after reading that article alone, how you were supposed
to *know* if you had that software installed though.
There were no tell-tale signature files to look for listed.
> Apparently, in 2015, the US government advised uninstalling that
> software that came bundled with Lenovo products because of a root
> certificate security issue.
to *know* if you had that software installed though.
There were no tell-tale signature files to look for listed.
Richard Kettlewell
Jun 14, 2015, 7:31:46 PM6/14/15
to
article..
--
http://www.greenend.org.uk/rjk/
David W. Hodgins
Jun 14, 2015, 8:23:02 PM6/14/15
to
shouldn't be doing, their ability to sign certificates is revoked, so
all certificates they've signed immediately become invalid too.
https://en.wikipedia.org/wiki/Revocation_list
Michael Baeuerle
Jun 15, 2015, 4:08:05 AM6/15/15
to
David W. Hodgins wrote:
was revoked. CRLs can be large (e.g. several megabytes for CAcert) and
with a low bandwith connection it can hurt downloading them on-the-fly
while opening a connection.
WWW browsers normally prefer OCSP for revocation checking, but then
nevertheless accept the certificate if they get no response.
Because of this weak revocation system, it is a good idea to set the
validity period of certificates not too far into the future (so at least
the expiration eventually invalidate the certificate).
> Werner Obermeier wrote:
> >
> > This is what scares me about the so-called 'root' certificates.
> > If they're stored on my machine (either by the browser or the OS),
> > then, anyone can put a malicious one there (since home machines just
> > can't be secured, period - when even government machines can't be
> > secured with huge IT departments protecting them).
> > So, isn't that an extremely weak link in the chain?
>
> Not really. When a certificate authority is caught doing things they
> shouldn't be doing, their ability to sign certificates is revoked, so
> all certificates they've signed immediately become invalid too.
> https://en.wikipedia.org/wiki/Revocation_list
The problem is that not all software don't check whether a certificate
> >
> > This is what scares me about the so-called 'root' certificates.
> > If they're stored on my machine (either by the browser or the OS),
> > then, anyone can put a malicious one there (since home machines just
> > can't be secured, period - when even government machines can't be
> > secured with huge IT departments protecting them).
> > So, isn't that an extremely weak link in the chain?
>
> Not really. When a certificate authority is caught doing things they
> shouldn't be doing, their ability to sign certificates is revoked, so
> all certificates they've signed immediately become invalid too.
> https://en.wikipedia.org/wiki/Revocation_list
was revoked. CRLs can be large (e.g. several megabytes for CAcert) and
with a low bandwith connection it can hurt downloading them on-the-fly
while opening a connection.
WWW browsers normally prefer OCSP for revocation checking, but then
nevertheless accept the certificate if they get no response.
Because of this weak revocation system, it is a good idea to set the
validity period of certificates not too far into the future (so at least
the expiration eventually invalidate the certificate).
0 new messages