Hi all,
I have some new information on this topic that I wanted to share. Some
of this information came from Steve Gibson's podcast, as he's been
talking about the subject, and I want to give credit where credit is
due. Other stuff, I've dug up on my own. I also have some more
questions, as I'm trying to determine the best way to deal with the 100+
passwords for sites I have stored in Lastpass.
Basically, from a consumer standpoint, the main elements in evaluating
the status of a site are the server software status and the cert
status. Here are the basic permutations of that, and the basic
reactions that I think are appropriate. I've been having an ongoing
dialog with a Lastpass support tech, and he agrees with me regarding
this. In regards to their Heartbleed checker, he stated that they do
not mark a site as safe unless the site has patched the software AND
upgraded their cert. This information may come from press releases,
etc., so it doesn't mean that every site is tested by Lastpass. I'm
using ssllabs to test for server vulnerability. Also, I don't know if
Lastpass has a way to check for revocation of the old cert.
server vulnerable, cert (doesn't matter) - avoid logging in if possible,
if not possible to avoid, change passwords frequently
server safe, cert old - change password now and when (if) the cert is
updated
server safe, cert new - change password once
This is the strategy I think I'm going to use for all my passwords.
Even leaving old less important passwords unchanged could subject me to
danger if I log in later and that server was compromised.
Here is zendesk.com's press release, just as an example:
https://support.zendesk.com/entries/50648937-Important-announcement-about-the-security-of-your-Zendesk-communications
And part of their advice:
"Really, you should reset your passwords for all online services that
you use!"
So, that leads me to some questions. I have a pretty good way to test
if the server is currently vulnerable by using ssllabs server test.
However, when it comes to determining whether the cert is updated,
that's a bit harder. As I said, Lastpass doesn't mark a site as safe
unless they think the cert update has been done. But, what if you
actually want to know the date?
Let's take zendesk.com for example. If I run the ssllabs test on it, it
says the server is not vulnerable (as expected, since they say they
patched it).
The valid from date on the cert says Wed Sep 07 00:00:00 UTC 2011.
However, the press release says they replaced the certs on Apr 9th.
So, there is a conflict between the valid from date and the press
release. The Lastpass site checker says zendesk.com's cert is now safe,
but they don't say how they know that. I'm assuming that zendesk.com IS
safe, considering the press release.
But, how can I tell if the cert is really safe? How can I tell if the
cert was really updated ... barring having a press release? I need to
know this to implement my strategy and determine if I have to change the
password once or twice. I'll probably rely on Lastpass' assessment if I
don't have a better source.
I'm not totally sure if changing the password the second time, after the
cert is updated, really does much, but it seemed like a good idea.
There is a pretty intense discussion by crypto type geeks going on on
the Lastpass blog about the effect of this thing on Lastpass. There's a
big debate as to whether, if Lastpass was vulnerable before, what the
likelihood is that someone could breach your password database. I
cannot understand the discussion, as it's over my head and over my
knowledge of crypto, but I've decided to change my master Lastpass
password and put the issue to bed, at least in my mind. The blog itself
(by Lastpass) has lots of good info, but you have to click on each entry
to see the comments and discussions. Lastpass' public position is that
a master password change is unnecessary, but it's fine if you do so.
http://blog.lastpass.com/
http://blog.lastpass.com/2014/04/updating-passwords-in-wake-of-heartbleed.html
http://blog.lastpass.com/2014/04/lastpass-now-checks-if-your-sites-are.html
http://blog.lastpass.com/2014/04/lastpass-and-heartbleed-bug.html
I'm really impressed with Lastpass and their actions to help their
customers understand this and get through this. They're going way
beyond what it takes just to support their product. The customers have
been "burning up" their blog and trouble ticket system with questions.
They've even added a Heartbleed checker to their normal Security Check
tool to help the users. Very cool.
The following, which comes from Steve's podcast, may be a possible way
to check the cert dates.
http://data.networknotary.org/notary_web/notary_query?host=lastpass.com&port=443
This loads very slowly, but it shows the date ranges for the key
fingerprints observed on lastpass.com. You can change the website to be
checked in the link, but I think you have to have something in there for
an automated test. You can also manually change the site to test once
you get there.
They also have a firefox extension:
http://perspectives-project.org/firefox/
Here's the main site, and how they describe themselves:
http://perspectives-project.org/
http://perspectives-project.org/about-us/
"Perspectives is a new approach to helping computers communicate
securely on the Internet. With Perspectives, public “network notary”
servers regularly monitor the SSL certificates used by 100,000s+
websites to help your browser detect “man-in-the-middle” attacks without
relying on certificate authorities."
I'd be interested to know what you guys think of it.
OCSP is a mechanism in the browser that checks with the certificate
authority to determine if an ssl certificate is valid.
So, the CA knows which ssl sites you're hitting, at least the ones that
they generated the certs for. As I understand it, Firefox has had OCSP
defaulted to on since v3. OCSP stapling is a newer technology which is
supposed to address the privacy concerns, and some performance scaling
concerns. I believe Firefox has had OCSP stapling since v26, or since
July 2013.
http://en.wikipedia.org/wiki/OCSP
http://en.wikipedia.org/wiki/OCSP_Stapling
https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
However, Firefox still connects to the site if it cannot get OCSP or
OCSP stapling data by default. There is a way to force Firefox to
refuse to connect in this case, but it reduces usability if the OCSP or
OCSP stapling data is not available.
This article shows how to turn OCSP off, but if you do the opposite
steps, you can turn it on, or back on.
http://connectionfailure.wordpress.com/2011/10/27/switching-off-ocsp-in-firefox/
You go to about:config, click the button that says you'll be careful,
and search for ocsp. Look for the following options.
security.OCSP.enabled - defaults to 1 - reset to 1 if OCSP is off and
you want to turn it back on
security.OCSP.require - defaults to false, set to true (double click) to
force connection failure without valid OCSP or OCSP stapling data
I think I'm going to try setting this latter option to true for a while
and see if it causes too much pain. Here's an article that discusses
the implications of the require option.
https://groups.google.com/forum/#!topic/mozilla.dev.security/n1G-N2-HTVA
I was tinkering with the Firefox menus, and I found that there is also a
way to control the ocsp functions mentioned below in the quote via the
GUI. Go to tools, options in Firefox for Windows (or edit, preferences
(I think) in Firefox for Linux), then advanced tab, certificates sub
tab, then click the validation button. Two check boxes are presented.
The first tells Firefox to use OCSP for cert checking, and this is
normally on. The second tells Firefox to treat the certificate as
invalid if OCSP fails. This would normally be off. In other words,
normally, if OCSP cannot be checked, the connection to the site is still
made. Turning this box on will cause a hard fail and the connection
will not be made. Having both boxes on is the safest approach, and is
the same as the about:config changes outlined above.
It is very important that your browser at least warn you if you've gone
to a site with a revoked ssl certificate. But, how do you test that?
Steve Gibson, of the security now podcast ( https://grc.com/securitynow
) has now posted some pages on his site that let you test your browser
for its certificate revocation awareness without the worry of going to a
hacker site.
You can get basic info here:
https://www.grc.com/revocation.htm
The interesting things start happening when you click the next link:
https://revoked.grc.com/
This subdomain has a deliberately revoked ssl certificate. Your browser
should NEVER get to the page behind this link. You as a user should not
see the page if things are working properly.
So, you can test how your browser responds to the situation.
Unfortunately, the Dolphin browser on my tablet just blasted right on
through and never cared that the certificate was revoked. It apparently
didn't even check it. It didn't give me a warning, even though I have
security warnings on. Nothing. This is very disconcerting.
If you DO end up seeing the 2nd page, you will find some similar
verbiage to enlighten you as to what just happened. It goes out of its
way to warn lay people that they shouldn't be seeing the page in the
first place and that there is a problem with the browser they're using
with text such as:
"this web browser is allowing a site with a known invalid certificate to
display its pages. This is likely not the behavior you would choose"
"This means that this web browser will not detect and warn you if you
visit a fraudulent website that is using a revoked certificate that is
known to the REST of the Internet to be bogus. YOU won't know."
I think this is a very handy quick and safe way to do the test, and can
be useful to use quickly on any browser you choose. It could also be
useful for giving to friends and family to check their browser config.
You may want to test all your browsers right now, and particularly your
mobile ones. You may be surprised what happens, as I was.
Hope this info is helpful. Let me know what you think about the cert
date issue and the changing the password twice concept and the
perspectives project.
Sincerely,
Ron
--
(PS - If you email me and don't get a quick response, you might want to
call on the phone. I get about 300 emails per day from alternate energy
mailing lists and such. I don't always see new email messages very quickly.)
Ron Frazier
770-205-9422 (O) Leave a message.
linuxdude AT techstarship.com
_______________________________________________
tech-chat mailing list
[email protected]
http://lists.linuxmoose.com/mailman/listinfo/tech-chat
