Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Has Gmail's SSL Certificate Changed, How Would We Know?

samzenpus posted 1 year,28 days | from the protect-ya-neck dept.

Security 233

An anonymous reader writes "Recent reports from around the net suggest that SSL certificate chain for gmail has either changed this week, or has been widely compromised. Even less-than-obvious places to look for information, such as Google's Online Security Blog, are silent. The problem isn't specific to gmail, of course, which leads me to ask: What is the canonically-accepted out-of-band means by which a new SSL certificate's fingerprint may be communicated and/or verified by end users?"

Sorry! There are no comments related to the filter you selected.

Revocation (4, Insightful)

Anonymous Coward | 1 year,28 days | (#44967853)

Google can easily revoke certificates. They can even install what ever they want on my computer as a replacement for google chome with their automatic background updates. Don't worry about it, they own your computer and will take care of it for you.

Re:Revocation (0)

Dexter Herbivore (1322345) | 1 year,28 days | (#44967929)

I wouldn't particularly worry unless it was signed by the NSA.

Re:Revocation (1)

Anonymous Coward | 1 year,27 days | (#44968463)

Why worry even then?

We are talking about communicating with Google here. Your ISP might perform a Man in the Middle attack against you on behalf of NSA, but it seems more likely that NSA would just ask Google for the the information if they want it.

Encryption is only useful to prevent middle points from snooping. That is nice I guess but it is probably more useful for NSA than it is for average Joe.
The main concern that we ordinary people have is that we don't know if we can trust the endpoint, that is not something you can solve with good encryption.

Re:Revocation (1)

smash (1351) | 1 year,27 days | (#44968899)

Thing is, you won't know if it was signed by the NSA if they have google's private key.

Revocation --- or Redundancy? (5, Interesting)

ron_ivi (607351) | 1 year,27 days | (#44968221)

I wonder why HTTPS stuff can't require *two* certificates that validate. That way unless both CAs are compromised, the traffic's safe.

It's just like any other single-point-of-failure in your network. You probably work with two telcom companies to make sure your website and/or company has network access. Why shouldn't you do the same for certificates. Buy one from a US CA, one from a Russian one, and one from a Chinese one, and if browsers could check to make sure *all* (or two out of the three, whatever) validate, unless they collude you should be pretty safe.

Even better if one of those can be a self-signed one. You can even exchange those keys over normal boring https, and then unless your commercial CA was already hacked at the time you distribute your self-signed one, your self-signed one will protect against your commercial CA being hacked in the future.

Re:Revocation --- or Redundancy? (1, Insightful)

the_B0fh (208483) | 1 year,27 days | (#44968529)

And for more security, we can do *THREE* certificates. Count them! *THREE* for additional security.

Super secure sites like banks can do *FOUR* certificates. If any one of the *FOUR* certificates break, then we know we're attacked! Even more secure if those *FOUR* certificates come through 4 different ways...

Are you really suggesting that?! Do you even know how PKI works?

Re:Revocation --- or Redundancy? (5, Informative)

petermgreen (876956) | 1 year,27 days | (#44968593)

Do you even know how PKI works?

Currently PKI works by having a large number of certification authorities (both roots installed in the browser and intermediates with delegated authority from those roots) any one of which can issue a certificate that will be trusted by the browser to identify a site. So if any one of those certification authorities is compromised by an attacker then the attacker can obtain a certificate with which they can MITM traffic to your site without generating any warnings.

AIUI What the GP is proposing is that multiple independent authorities would need to vouch for a "high security" site so that one compromised certification authority would not be sufficiant to perform a man in the middle attack. It's a nice idea in principle but there are several practical issues to deal with.

1: How do you define independent authority. I'm sure there are cases where multiple root certificates are controlled by the same entity.
2: How do you decide what sites it should apply to. One possibility would be to never allow the number of authorities for a site to go down so once a site had been seen with more than 1
3: How do we modify the protocols to support this.
4: How do we convince site operators to adopt this.

Re:Revocation --- or Redundancy? (1)

TheRaven64 (641858) | 1 year,27 days | (#44968711)

The problem is that there's no well-supported way, for example in the DNS, for a server to say which certificate it will use. If HTTPS required two certificates, then that would just mean that you'd need to compromise two CAs (or one CA and get them to issue two certs), which given what we already know about the NSA program, has already happened. This is something that people like Ben Laurie at Google are working on with Certificate Transparency: trying to ensure that there is a recorded and verifiable chain showing that a certificate was issued to the real owner of the domain and that it is not being MITM'd.

Re:Revocation --- or Redundancy? (0)

Anonymous Coward | 1 year,27 days | (#44968913)

Having DNS supply the certificate would just mean you have to compromise DNS, too. If you can compromise a certificate, you probably can compromise DNS as well. Especially if you are the NSA, and have in your country the company which controls the root servers.

Re:Revocation (0, Troll)

hairyfeet (841228) | 1 year,27 days | (#44968527)

And this is why since they updated their privacy rules I no longer recommend Chrome and have switched to Bing search, I don't have any other MSFT services so they can't get anything other than my searches and frankly they way Google has been bugging the piss out of me lately to use my RealID, even on the phone, has really turned me off.

For those that like Chrome but not the phone home there are several choices, I personally use Comodo Dragon as it has several added security features, then there is SWIron, Chromium, or if you want to go back to the source and care about cross platform there is QTWeb which is just what it sounds like, Webkit with a QT based UI. This is one big advantage we have over the days of just IE and NS, today there are so many browsers you can choose one that fits you and does what YOU want, no need to just take what the corp hands you anymore.

Re:Revocation (1, Insightful)

Anonymous Coward | 1 year,27 days | (#44968617)

Hairy...so you turned into a full-fledged Microsoft shill now?

I (and a few others) knew you were a Microsoft shill from the beginning. But most of the time you were quite subtle and it was difficult to pin you down. But it looks like your account is converging with the other SharkLaser type accounts now. Did you join Burson marseller?

Re:Revocation (1)

Anonymous Coward | 1 year,27 days | (#44968933)

How does "I don't have any other MSFT services" fit to being a Microsoft shill? Note that he didn't even recommend IE, as any true MS shill would have done.

He's obviously anti-Google (and since the only true non-Google search engine worth mentioning these days is Bing -- all other search engines either use Google or Bing underneath --, it is not that much of a surprise he mentions Bing as alternative search), but that's different from being an MS shill.

Re:Revocation (4, Funny)

houghi (78078) | 1 year,27 days | (#44968787)

google chome with their automatic background updates.

That is why I use Firefox. I installed it when it was version 7 and it still is version ... (Checks version) ... How did it get to this version 23?

Re:Revocation (2)

bsane (148894) | 1 year,27 days | (#44969031)

Firefox checks and updates when you run it. On OSX Chrome creates a launch service that keeps a daemon running that constantly communicates back with goog- even if you never open chrome again. Delete chrome? Background daemon continues to talk to goog- it doesn't go away until you use the CLI to remove it.

Google announced this (5, Informative)

supersat (639745) | 1 year,28 days | (#44967865)

Back in May, Google announced that they would be making changes to their SSL/TLS certificates in the coming months: http://googleonlinesecurity.blogspot.com/2013/05/changes-to-our-ssl-certificates.html [blogspot.com]

If you use Chrome, Google's SSL certificates are pinned, so that gives you some additional assurance.

Re:Google announced this (5, Informative)

Trax3001BBS (2368736) | 1 year,27 days | (#44968575)

Back in May, Google announced that they would be making changes to their SSL/TLS certificates in the coming months: http://googleonlinesecurity.blogspot.com/2013/05/changes-to-our-ssl-certificates.html [blogspot.com]

Oh No's!
"Even in less-than-obvious places to look for information, such as Google's Online Security Blog, are silent."

To a non-story
"Back in May, Google announced..."

Thanks for that.

Re:Google announced this (1)

Anonymous Coward | 1 year,27 days | (#44968693)

That announcement says that Google is moving to 2048 bit keys. However, the mail.google.com key that I get was issued on September 11, 2013 uses 256bit ECC keys. What gives?

Re:Google announced this (4, Informative)

spottedkangaroo (451692) | 1 year,27 days | (#44968889)

ECC keys are shorter than RSA keys. 256 ecc is like 3072 rsa bits.

Expiry (2, Informative)

jamesh (87723) | 1 year,28 days | (#44967895)

Was the old cert due to expire? I have thought before that it would be nice if my browser etc gave me a warning like "Certificate has changed but wasn't due to expire for another 3 months". This still gives the bad guys a window where a subverted certificate could be slipped in without notice, but it closes the window a bit.

Also is it common to revoke the old certificate when replacing it, even if there is no reason to suspect the old certificate was compromised? If so that would be another warning that could be presented

Re:Expiry (4, Informative)

Anonymous Coward | 1 year,27 days | (#44968303)

I use with Firefox the Certificate Patrol add-on for detecting, when the certificates are changed. At least then you know, when the certificate has been changed.

Re:Expiry (2)

pe1chl (90186) | 1 year,27 days | (#44968491)

Unfortunately it issues warnings all the time, especially for google and twitter.
They occur so often that you (or at least me) get the habit of accepting them without further checking, to be able to continue working.
This largely defeats the usefulness of this add-on.

It appears that google twitter use different certificates on different servers around the world, and you get those warnings when
the loadbalancing mechanisms direct you to another server you were using last time (for the same domain name).
Either that, or their communications are intercepted by the local security agency who acts as a man-in-the-middle.

How would you know?

Re:Expiry - maybe? (1)

Anonymous Coward | 1 year,27 days | (#44968809)

Was the old cert due to expire? I have thought before that it would be nice if my browser etc gave me a warning like "Certificate has changed but wasn't due to expire for another 3 months". This still gives the bad guys a window where a subverted certificate could be slipped in without notice, but it closes the window a bit.

Maybe. If I skip the web browser and run: msmtp --serverinfo --host=smtp.gmail.com --tls=on --port=587 --tls-certcheck=off

I get:
Activation time: Tue Sep 10 00:54:47 2013
Expiration time: Wed Sep 10 00:54:47 2014
SHA1: 10:75:E1:8C:DF:93:15:3B:A1:8F:CD:FE:D3:11:79:D5:16:43:77:BC

That's a pretty recent change. If there was overlapping time between the activation of this one and the expiry of the last one... problem is, I don't have a time machine and can't find out what the last one was, nor when it was set to expire.

Googling (look, just because they can MITM every site, I don't think even NSA is doing DPI on every HTTP transaction so they can pipe every web page through 'sed s/valid-signature/fake-signature/g' :) around for prior signatures reveals:

As of June 19, 2010 [gmane.org] : Activation time: Thu Apr 22 21:02:45 2010
Expiration time: Fri Apr 22 21:12:45 2011
SHA1: 1A:6F:48:8F:BE:5B:FD:92:D8:12:30:F9:22:CE:84:49:B3:43:BD:2C

As of August 16, 2011 [github.com] : Activation time: Wed Feb 16 12:38:09 2011
Expiration time: Thu Feb 16 12:48:09 2012
SHA1: DB:A0:2A:07:00:F9:E3:23:7D:07:E7:52:3C:95:9D:E6:7E:12:54:3F

As of October 2, 2012 [google.com] , another user reports a change from:
SHA1: F3:92:AE:B4:28:FE:64:03:6F:E1:55:ED:71:9E:5F:F6:88:90:5A:57
to:
SHA1: 34:B4:3E:66:71:D8:AC:5A:47:76:7F:B7:CD:E4:31:08:F4:A5:DD:A8
but didn't include the dates.

There was also a 2013 hit for what looked like a tls_fingerprint of 52:99:F2:7F:82:4F:79:5A:71:1F:FF:D3:BE:22:7C:88:06:62:89:76 also without dates.

So on the one hand, this may simply be an innocuous expiry of a cert for smtp.google.com that's related to this May 2013 note about upcoming changes [blogspot.com] . On the other hand, there's nothing else that says what the old fingerprint was, when it expired, nor what the new fingerprint ought to be. And on the gripping hand, maybe the root (if you'll pardon the pun) cause of the problem is that if the the user has no tls_trust_file defined, and if Google changed intermediate certificate authority [google.com] ... umm, dammit, now even I'm confused. I think I sympathize with OP, though. There needs to be an easy-to-google, bing, apt-get, or git-init means by which of seeing the history of what's legit at any moment in time. It's up to the user to decide how many ISPs to run the search query from, or even to pick up the phone and call a friend in a non-US country and ask them to do the search and see if they get the same results.

Why do we trust SSL? (5, Insightful)

JWSmythe (446288) | 1 year,28 days | (#44967921)

    That made me wonder about something at work recently. All the machines at work are owned by the organization. It would be trivial for them to add their own trusted signing authority, so they could MITM every SSL web site. It wouldn't be terribly hard to auto-generate "valid" SSL certs, and have it tagged as whoever you want the signing authority to be. All they'd have to do is add their own cert, in this case named "GeoTrust Global CA", and they'd have perfect control. To do it perfectly, they'd just need to query the site you're going to, and match up the signer's CN and sign the new fake cert, and you wouldn't know the difference. Who tracks the fingerprint of every cert for every site they go to? Well, I'm sure in this crowd, a few do.

    It's good for network security, as they can pump everything out through a common proxy (or cluster of proxies) and inspect all the traffic for malicious intent (malware inbound, or organization secrets outbound). It's not good for privacy, if you were to visit your bank, gmail, etc.

    As far as that goes, there are an awful lot of "trusted" signing authorities that come with any browser. I know we should probably trust them, because the authors of the browsers trust them. There's no really good reason to do so, other than if you don't, all SSL sites will warn that they may not be trustworthy.

    I was considering a while back, how would *I* become my own signing authority, to be trusted by all browsers. I didn't find a good answer. An intermediary cert would solve it, but I didn't find how to accomplish that. Like, who do I throw money at to get one. Getting added to all browsers would be another even larger headache.

    My thought on it was, technically it isn't hard to do. I could spend a day writing a very nice site, that would verify ownership and make whatever cert for the domain. Why can't I (or whoever) offer $5/yr, or $50/10yr single domain or wildcard cert? The code and infrastructure isn't very heavy.

    Needless to say, since you haven't seen JWSmythe's Cheap Certs available, it never happened.

Re:Why do we trust SSL? (1)

Anonymous Coward | 1 year,28 days | (#44967955)

My employer DOES do this. They use a websense SSL proxy, and every https site you visit will be "signed" by their internal certificate.

Re:Why do we trust SSL? (1)

Anonymous Coward | 1 year,27 days | (#44968827)

My Old employer did this, in a very half assed manner (it was government) which ended up having you get warnings for every site on the internet, including google.com and in some cases, an endless loop of trying to enable a site because the certificate can't be verified, to end up right back at the first warning screen again. It's actually not that hard to setup a self signed certificate authority, it really isn't, but if you don't know what you are doing, you will cause your employees so much trouble and headaches (invalid certificate for intranet application? REALLY?) that they will start turning on the tethering on their phones and bypass your network altogether, creating a massive security breach, cause I don't know about your phone, mine doesn't seem to have a firewall or any type of protection what so ever.

Re:Why do we trust SSL? (1)

LordLimecat (1103839) | 1 year,28 days | (#44968009)

Forge the CA, and the signing CA's thumbprint on the cert wont match. That would be sort of obvious and easy to see, sort of like how these guys are spotting this now.

Its possible this IS an NSA or whomever MITM, but I sort of doubt it precisely because of how easy to spot it is.

Re:Why do we trust SSL? (1)

smash (1351) | 1 year,27 days | (#44968903)

Why forge the CA when you can just buy them?

Re:Why do we trust SSL? (1)

cheater512 (783349) | 1 year,28 days | (#44968015)

If you look hard you can detect that very easily. Both the additional CA on your computer and patterns in the generated certificates.

Yes you do have to be looking for it, but once you look it is dead simple.

Getting the fingerprint in JS (2)

Richard_J_N (631241) | 1 year,27 days | (#44968719)

I operate a webserver, and I'd like to protect my users against SSL proxying. At the moment, all I can do is tell them to check my key's fingerprint against what the browser shows. But I'd really like to do this in JS. Is there any way to use JS to get the fingerprint string (that I can see by clicking on the padlock icon)? Then I could send that back to the server (from JS), and check if it's been tampered.

(A really effective evil proxy would be able to defeat this, but most corporate proxys aren't going to be able to parse my own JS and work out precisely how to transparently defeat it).

Re:Getting the fingerprint in JS (1)

cheater512 (783349) | 1 year,27 days | (#44969121)

No JS cannot get any SSL information.

Perhaps hash the page you send and check the hash in JS? If they are sending sensitive information then use a JS strong encryption library which adds an extra layer in the browser.

Again dead simple to break if someone is targeting you specifically, but it would have to be a custom hack for your site.

Re:Why do we trust SSL? (5, Insightful)

forkazoo (138186) | 1 year,28 days | (#44968025)

That made me wonder about something at work recently. All the machines at work are owned by the organization. It would be trivial for them to add their own trusted signing authority, so they could MITM every SSL web site. It wouldn't be terribly hard to auto-generate "valid" SSL certs, and have it tagged as whoever you want the signing authority to be. All they'd have to do is add their own cert, in this case named "GeoTrust Global CA", and they'd have perfect control. To do it perfectly, they'd just need to query the site you're going to, and match up the signer's CN and sign the new fake cert, and you wouldn't know the difference. Who tracks the fingerprint of every cert for every site they go to? Well, I'm sure in this crowd, a few do.

It's not merely possible. It's deployed, off the shelf technology. Not necessarily common, but many companies that do it see it as a cost reduction of more effective proxy usage, rather than anything nefarious.

That said, the way SSL is handled by the browsers is absurd. Not notifying on changes compared to a cached fingerprint, and giving huge warnings on self certification are blatantly obvious errors in judgement. Conflating encryption and identity in one awkward mess has probably done more harm than good. IMHO, it should work a bit like SSH, where the first time you go to a website, you see a little unobtrusive popup saying, "This connection is encrypted. The site claims to be "Foo corp." The identity is (not verified || vouched for by the following : CA Bar, CA Baz). " Adding certs for CA's should be really obvious, not obscure black magic. So, if you attend University of Foo, you can add their self signed cert and all the servers on campus that you access over https will show up as signed by U of Foo. Untrusting certs should also be obvious in the UI. Some web of trust model should be available. If you ever get something other than what was cached, you should see the details side by side.

As is, the system is mostly useless. It fails utterly at identification. And, it scares people away from using encryption on self signed certs. (As if that were somehow worse than operating entirely in plain text...)

Re:Why do we trust SSL? (1, Informative)

AK Marc (707885) | 1 year,27 days | (#44968129)

And most commercial sites do the same. They call it "reverse-proxy) and is done because web server software sucks at encryption. So if you are mobing 10 Gbps of encrypted web traffic, you put an encrypting proxy 1RU above the server, and the server serves pages, and the proxy encrypts them. Well, it's usually a little more complicated than that, but that's the general idea. I've done it. It is that easy.

Re:Why do we trust SSL? (1)

Anonymous Coward | 1 year,27 days | (#44968327)

And most commercial sites do the same. They call it "reverse-proxy) and is done because web server software sucks at encryption. So if you are mobing 10 Gbps of encrypted web traffic, you put an encrypting proxy 1RU above the server, and the server serves pages, and the proxy encrypts them. Well, it's usually a little more complicated than that, but that's the general idea. I've done it. It is that easy.

That's different. They're the owners of the CN and therefore have a 100% valid certificate for it. They're not messing with your CAs at all. Everything's done at the server end.

The GP is talking about when companies install their own custom CA on company machines. That's at the client end and potentially compromises your security...

Beyond making packet traces by the company possible, if you access a site with a bad certificate the proxy handles that for you, and if it does so silently you have absolutely no idea anything is wrong. And if it blocks it you can't bypass it for legitimate sites (self-signed).

Re:Why do we trust SSL? (4, Insightful)

steelfood (895457) | 1 year,27 days | (#44968147)

The current implementation in web browsers was designed by people who couldn't tell the difference between authentication and authorization.

The reason why this paradigm has persisted is unknown, but the answer for you may vary depending on which end of the paranoia spectrum you're on. If you're on the Hanlon side, you'd say that the code is too old, and trying to change it would require too much work, so nobody really bothered. If you're on the conspiracy nut side, you'd say that the NSA and their agents are actively trying to keep these types of changes from going in.

This problem with SSL certs has been known for the better part of 10 years now, and has been in focus for at least the past 5-7 years. Why Firefox could go through 30 revisions in that time and keep this behavior while changing practically everything else is quite the mystery. I'd say the same about Opera or IE, but they're closed-source and hence could not be subjected to the same standards of scrutiny. In fact, if there ever was a failure to the OSS model security-wise, Firefox's 1990's method of handling certs would be a prime example.

Re:Why do we trust SSL? (1)

mvdwege (243851) | 1 year,27 days | (#44968281)

Conflating encryption and identity in one awkward mess has probably done more harm than good.

I suggest you go back to school. Encryption without authentication is useless.

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968355)

Why?

Re: Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968441)

Because if you don't know who you are establishing an encrypted session with, you could be talking with a man in the middle. The point of having the encryption was to protect your communication with who you wanted to talk with.

Re: Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968449)

Because if you don't know who you are establishing an encrypted session with, you could be talking with anyone. The point of having the encryption was to protect your communication with who you wanted to talk with.

Re: Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968503)

Yet, for a lot of cases, all you care about is that you're talking to the same server you were talking to before. For example, when logging into a forum, all you care about is that the server is the same as the one you registered an account on -- that you're not submitting your credentials to a third (hostile) party. A self-signed certificate is more than sufficient for that.

Re: Why do we trust SSL? (2)

philip.paradis (2580427) | 1 year,27 days | (#44968649)

No, a self-signed certificate is not sufficient for what you're describing, or anything requiring actual security, unless you've set up your own CA in advance and added the corresponding root CA cert to your local PKI store (in the case that you're the operator of the forum), or added the root CA cert the forum is using (if any formalized CA infrastructure is being used at all on their end, given it's a self-signed cert) via an out-of-band source that you have reason to trust, or have a trustworthy out-of-band means of verifying the digital fingerprint of the certificate you're being presented with in the first place. The fundamental issue is simply that otherwise, the first time you visit the hypothetical forum site to register an account, you have no means of determining whether you're speaking directly to the forum server or a man in the middle. Men in the middle can be your ISP, the feds, whoever, and can have shall we say rather persistent presences in Internet architecture.

Please, please, please stop spreading misinformation like this. Please educate yourself, starting with Applied Cryptography. If you're not willing to speak intelligently on this topic, kindly stop misleading others and make your own mistakes in silence.

Re: Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968741)

I thought I stated it perfectly clear that it is sufficient to _verify_ that you're speaking to the same site as _before_

By your logic, OpenSSH must have a gaping security flaw since it has nothing but 'self-signed' certificates. [1]

And if the man in the middle is the feds, they certainly have their own CA-approved certificate they can MITM with which your browser trusts without batting an eyelash. For these cases, an out-of-band method of verifying the key is the only way to get security.

[1] I do agree that you should verify the key out-of-band if possible.

Re: Why do we trust SSL? (2)

philip.paradis (2580427) | 1 year,27 days | (#44968839)

You stated, and missed the point of, the entire problem here, namely initial connection verification. OpenSSH should be treated in exactly the same manner, as it relies upon PKI in the same manner. Out of band fingerprint verification is essential to ensuring the integrity of such communications, which I'll reiterate you utterly failed to mention in your post while you were busy espousing the virtues of self-signed certs without any further guidance on the concerns associated with them. I verify every single key I accept via highly trusted out of band means. I'm fairly certain if I asked you how you'd manage to perform such verification, you'd spend fifteen minutes madly Googling answers and likely winding up parroting various one-liners you found on half-baked newbie forums (with self-signed certs, natually) to attempt to prove your expertise.

To address your second point, I'm not saying the feds haven't compromised large scale commercial CAs through friendly visits, but that's really not at all the most efficient means of intercepting and decrypting comms at wire speed. I say this as someone who could build you the infrastructure required to do that.

In short, stop talking and start learning. Shut your mouth for a few years to avoid dispensing horribly misleading "advice" to others in the general community, and have a nice day.

Re: Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968873)

Who cares if your initial registration goes to the attackers? They get a login+password combo. The account has no value. The credentials you should guard are for the account that has value -- the account you have been using for a couple of years. The one that has a reputation or moderator access or whatnot.

I have never said that self-signed certificates are perfect, but it's foolish to imply that they're close to worthless just because a higher form exists.

I fully stand by my original statement, and it is you who is twisting my statement.

Re: Why do we trust SSL? (1)

philip.paradis (2580427) | 1 year,27 days | (#44968947)

You are the worst brand of stupid, the kind who is more interested in preserving his own ego than dealing with problems effectively. If you'd bother to spend ten seconds thinking about the core problem here, you'd realize that people have far more to worry about at the network edges of their destinations than they realize. Have you considered the possibility that those edges might be inclined to probe inward and check the trust chain associated with the destination, and maybe just maybe take selective action based on that information? Do you have any idea what sort of ramifications that scenario holds aside from dirt simple logging of the packets in transit, things like modification of the payload for whatever purposes the attacker desires?

I'm sick of being nice about this. Just shut the fuck up.

Re: Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44969107)

I'm not interested about my ego -- I'm an AC, remember?

I still think that self-signed certificates are an excellent way of getting encryption, packet integrity, /and/ verifying that it is still the same server. I cannot find anything in your posts that would refute that fact or why it would be misinformation.

(Your assumption seems to be that the attackers already control the infrastructure during the initial connection. My tinfoil hat is not /that/ tight. Besides, how would a "real" someone-else-vouched-for-me certificate help at that point?)

I certainly don't disagree with out-of-band cert verification and would try to offer a method to do that. Running an own CA would be a step up but mostly useful for larger projects only (Debian does it) -- hardly so for a hypothetical forum with only a single access point.

And hey, I freak out every time the certs expire/change without clear advance warning. Gmail's changed just the other day. And so did another e-mail service's, not too long ago. I should add their CAs to my trust list.

Re: Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44969037)

On the initial connect, I do not worry whether or not the web shop I'm connecting to is on East Street or West Street. What I worry about is whether or not I can trust the people behind the site, and certificates do not tell me that. All the certificate tells me is that this is really the shop on East Street, but that does not prevent me from getting ripped off, when it turns out that the one West Street is the honest one.

When I have successfully shopped there, and no fradulent withdrawals appeared on my bank statement, I am interested in ensuring that I am shopping at the store I trust.

Re: Why do we trust SSL? (1)

grahamm (8844) | 1 year,27 days | (#44969073)

Which is why organisations such as financial institutions should publish their certificate fingerprint 'out of band', for example on the back of the credit/debit cards and on every (paper) statement they send you.

Re:Why do we trust SSL? (1)

swilver (617741) | 1 year,27 days | (#44968413)

Spoken like a true short-sighted authentication nut.

Re:Why do we trust SSL? (1)

petermgreen (876956) | 1 year,27 days | (#44968661)

I disagree. Yes there is a risk that you will end up talking to a man in the middle if you use encryption without authentication. However

1: The attacker does not know if you are performing authentication on a given connection or not. Therefore by attempting to MITM your connections he risks being noticed.
2: MITM is a lot more effort than passive sniffing.

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968907)

Only against active adversary. And active attacks cannot scale. Sure, there are cases, when you must account for active attacker too (and you should be very careful about mixing those two cases), but even "opportunistic MITM-vulnerable by design encryption" would be big improvement over current situation.

Re:Why do we trust SSL? (5, Insightful)

VortexCortex (1117377) | 1 year,27 days | (#44968285)

That said, the way SSL is handled by the browsers is absurd. Not notifying on changes compared to a cached fingerprint, and giving huge warnings on self certification are blatantly obvious errors in judgement. Conflating encryption and identity in one awkward mess has probably done more harm than good. IMHO, it should work a bit like SSH, where the first time you go to a website, you see a little unobtrusive popup saying, "This connection is encrypted.

Yep, completely absurd. Go into your browser security certs and notice that the Chinese root cert "CNNIC" is installed. That means any of those trusted roots can simply create an SSL cert for Google.com and unless you're manually verifying the cert chain every time you connect, you won't know you've been MITM'd -- Big green bar and everything... I like your idea about making things more like SSH, but I'm afraid users will just click through it without reading any warnings anyway. Oh, if only PKI hadn't been invented! Why, then we could just use some session salt nonce HMAC'd with our pre-shared key (password) to set up a connection that no man in the middle can intercept (since they don't have our password, or password hash, etc pre-shared secret). I can do this in JavaScript, (or more favorably with a plugin), but we really need the browsers to just prompt us for the credential to our bank or email BEFORE it ever makes the request or displays the password entry form -- The request comes in, says : "I'm user X, here's my nonce, gimme your nonce server, and we can start encrypting data with HMAC( PW, N1 ) as the key". Public key crypto should have only ever been used at account creation (the only time you need to send the pre-shared secret). I've always known the entire security community was full of morons since they didn't bitch about the foolishness of SSL PKI loudly enough -- Oh, and for the "but muh passwerds!" folks: Built in password manager. Different random password for every site, master password to unlock the keystore. This is 2013 and since it's not standard addition to browsers, I'm not sure folks like you or me CAN do anything about it if we haven't already.

Additionally: People who searched for "Tinfoil Origami" also clicked on Convergence. [convergence.io]

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968683)

CNNIC? Theres 26 CA's in Opera - and CNNIC is not one I can see among them.

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,28 days | (#44968083)

Well, I'm sure in this crowd, a few do [check the certificates].

For those who don't already know it, there is a service at Gibson Research Corporation that helps you do that. https://www.grc.com/fingerprints.htm [grc.com]

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,28 days | (#44968091)

Certificate Patrol addon.
But I prefer using my SSH tunnel to secure my browsing activities while in "hostile" environments (work, client, hotel...)

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,28 days | (#44968093)

This is a common feature in most enterprise firewalls (Fortinet / Sonicwall etc), although it's generally referred to by more polite names such as "SSL Inspection".

Active Directory and most endpoint management software even provide convenient mechanisms to deploy CA certs to you on demand.

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,28 days | (#44968095)

There are proxy servers out there, "bluecoat", which does a man in the middle attack as you describe to let management look at your bank account and such.

Re:Why do we trust SSL? (4, Insightful)

citizenr (871508) | 1 year,27 days | (#44968163)

    That made me wonder about something at work recently. All the machines at work are owned by the organization. It would be trivial for them to add their own trusted signing authority, so they could MITM every SSL web site.

You just described for every enterprise firewall/scanner solution works

Re:Why do we trust SSL? (1)

myowntrueself (607117) | 1 year,27 days | (#44968165)

Where I recenty worked I was asked to build a proxy server to proxy and filter HTTPS traffic and to use group policy to distribute the wildcard certificate to the workstations. It was really easy, except for firefox which was a pain in the ass. I used Squid for the proxy server and SSL bump. It was very cool and very evil. I wanted to make sure that the CEO, who was asking for this, understood that I could use this to do whatever I liked to web pages, including his internet banking so I gave a demo where I did the old "upsidedownternet" for all SSL sites and explained that I could make it look like he had no money in his online banking or, in fact have no money. He still liked it though...

Re:Why do we trust SSL? (1)

smash (1351) | 1 year,27 days | (#44968911)

There are off the shelf devices for network acceleration designed for this exact thing: Riverbed Steelhead. Not nefarious, but for acceleration of traffic over slow network connections.

Re:Why do we trust SSL? (3, Insightful)

Nkwe (604125) | 1 year,27 days | (#44968169)

All the machines at work are owned by the organization.

You can stop right there. If the organization owns the machine, you have no expectation of privacy, legally or otherwise. From a technical perspective, if anyone other then you has administrative access to the machine, you should have no expectation of privacy. If you let malware gain administrative access, same story.

Re:Why do we trust SSL? (1)

Anonymous Coward | 1 year,27 days | (#44968851)

You can stop right there. If the organization owns the machine, you have no expectation of privacy, legally or otherwise.

The company owns the toilets as well. I do have an expectation that there will not be a camera there. I.e. I do have a basic expectation of privacy in my workplace and luckily where I live the laws are on my side.

Re:Why do we trust SSL? (2)

AmiMoJo (196126) | 1 year,27 days | (#44968961)

Actually it is illegal for companies to read personal email received at work in much of the EU. If you open gmail.com in a browser and check your mail at lunch time they are not supposed to spy on it. People have gone to jail for doing so.

Re:Why do we trust SSL? (1)

Anonymous Coward | 1 year,27 days | (#44968189)

What you describe is perfectly possible and in active use. Use this wonderful site to detect such cases: https://www.grc.com/fingerprints.htm Preferably print the page out and keep it in your pocket.

Re:Why do we trust SSL? (1)

Hypotensive (2836435) | 1 year,27 days | (#44968229)

As far as that goes, there are an awful lot of "trusted" signing authorities that come with any browser. I know we should probably trust them, because the authors of the browsers trust them. There's no really good reason to do so, other than if you don't, all SSL sites will warn that they may not be trustworthy.

I think you are confusing something here. It's not that the signing authorities are trustworthy in any general sense, it's that you believe that they are who they say they are. That's the only kind of trust that comes into play.

Re:Why do we trust SSL? (3, Insightful)

wvmarle (1070040) | 1 year,27 days | (#44968261)

As far as that goes, there are an awful lot of "trusted" signing authorities that come with any browser. I know we should probably trust them, because the authors of the browsers trust them. There's no really good reason to do so, other than if you don't, all SSL sites will warn that they may not be trustworthy.

The one and only reason you can trust them, is because if their trust is broken, the company is out of business really soon. Prime example of course is DigiNotar [wikipedia.org] which was declared bankrupt a month after a breach of its certificates came to light.

As soon as such a breach happens, browser vendors very quickly remove the offending certificate and push out a new update. Anyone using certificates from that vendor is forced to change almost instantly or people have issues accessing their web sites.

And that's the one and only reason you can trust them - and why that trust is fairly worthwhile.

Re:Why do we trust SSL? (1)

viperidaenz (2515578) | 1 year,27 days | (#44968435)

So place your trust in corporations, for corporate greed trumps all?

Re:Why do we trust SSL? (1)

the_B0fh (208483) | 1 year,27 days | (#44968547)

10 years ago, it cost $150k to put your own root into the browsers, each. I'm sure the price has gone up.

The reason wildcard certs aren't offered (actually, you could get them) is because each time you waste a couple of cpu cycles to get another cert signed, they get $$. Why kill the goose that lays dem elegant golden eggs?

Re:Why do we trust SSL? (0)

Anonymous Coward | 1 year,27 days | (#44968771)

Most current gen firewalls are capable of doing this.

They generally use their own generated CA cert, and distribute it internally (via GPO/whatever) so it's trusted.

Any URL filtering/application control system is kinda broken without that kind of capability, or at least easy to circumvent.

SSL (0)

Anonymous Coward | 1 year,28 days | (#44967923)

Dont trust SSL. In fact, dont trust anything related to US companies considering the NSA-scandal.

Re:SSL (1)

gweihir (88907) | 1 year,27 days | (#44968237)

Indeed. And there are others that will corrupt SSL and have enough clout to get Google to go along. The only situation where you can trust SSL is with self-signed certificates that you personally verified on both (!) ends of the connection. Otherwise, SSL may keep your little sister from snooping on your traffic, but that is it.

Re:SSL (1)

myowntrueself (607117) | 1 year,27 days | (#44968465)

Indeed. And there are others that will corrupt SSL and have enough clout to get Google to go along. The only situation where you can trust SSL is with self-signed certificates that you personally verified on both (!) ends of the connection. Otherwise, SSL may keep your little sister from snooping on your traffic, but that is it.

*Your* little sister doesn't work at the NSA.

Re:SSL (1)

gweihir (88907) | 1 year,27 days | (#44968629)

*Your* little sister doesn't work at the NSA.

Yes. And she would not snoop, she has intact personal integrity.

Convergence and Perspectives (4, Informative)

magic maverick (2615475) | 1 year,28 days | (#44967949)

From https://en.wikipedia.org/wiki/Convergence_%28SSL%29 [wikipedia.org] :

With Convergence, however, there is a level of redundancy, and no single point of failure. Several notaries can vouch for a single site. A user can choose to trust several notaries, most of which will vouch for the same sites. If the notaries disagree on whether a site's identity is correct, the user can choose to go with the majority vote, or err on the side of caution and demand that all notaries agree, or be content with a single notary (the voting method is controlled with a setting in the browser addon). If a user chooses to distrust a certain notary, a non-malicious site can still be trusted as long as the remaining trusted notaries trust it; thus there is no longer a single point of failure.

The Monkeysphere Project tries to solve the same problem by using the PGP web of trust model to assess the authenticity of https certificates.[8] [monkeysphere.info]

Now, everyone, let's use the tools available!

Detecting Certificate Change (5, Informative)

seawall (549985) | 1 year,28 days | (#44967963)

Addons for web browsers (e,g. Certificate Patrol in Firefox, there are others) can clue you into certificate changes. Rather like Ghostery (which shows where stuff is loading from in a web page): it is an eye opener.

Re:Detecting Certificate Change (0)

cerberusss (660701) | 1 year,27 days | (#44968105)

I love Ghostery, but it makes Safari 6.0.5 crash.

Detecting Certificate Inconsistency (2)

thegarbz (1787294) | 1 year,27 days | (#44968241)

While we're at it some other addons like Perspectives [perspectives-project.org] or Convergence [convergence.io] allow you to compare the cert you're receiving to the certs for the same site seen from multiple 3rd party servers across the world. This would allow you to confirm that not only that the certificate hasn't changed, but that the certificate you're seeing is the same one as *insert 3rd party unlikely to be MITMed the same time as you* is seeing.

Re:Detecting Certificate Change (1)

wvmarle (1070040) | 1 year,27 days | (#44968275)

It is pretty bad that the web browsers themselves don't do that.

If I change the key on my server, ssh refuses to connect until I remove the old key from my configuration. That's proper behaviour. That browsers don't even warn a key has changed is of course pretty bad.

Re:Detecting Certificate Change (2)

Foresto (127767) | 1 year,27 days | (#44968339)

Sadly, warning about certificate changes is practically useless today, since so many of the major sites have a bazillion different certificates, any of which might be the one you get at any given time. I stopped using Certificate Patrol for google sites because it was raising alarms almost every time I visited one.

answer... (0)

Anonymous Coward | 1 year,28 days | (#44967973)

> What is the canonically-accepted out-of-band means by which a new SSL certificate's fingerprint may be communicated and/or verified by end users?"

Certificate authorities, and in turn, root certificate authorities.

Re:answer... (1)

GigaplexNZ (1233886) | 1 year,27 days | (#44968259)

That's an in-band means.

You don't know (1)

AHuxley (892839) | 1 year,28 days | (#44967987)

As the NSA said in the 1970's ~NSA (“Wood Study”) "SIGINT sites were generally acceptable as long as they were invisible to the local population" page 393
from http://www2.gwu.edu/~nsarchiv/NSAEBB/NSAEBB441/docs/doc%201%202008-021%20Burr%20Release%20Document%201%20-%20Part%20A2.pdf [gwu.edu]
Welcome to the gift of free ENIGMA encoding with another rotor?

Certificate Transparency (5, Informative)

goddidit (988396) | 1 year,28 days | (#44968057)

Certificate transparency is a new project initiated at least partly by Google's engineers, which intends to solve this problem with SSL trust model: http://www.certificate-transparency.org/ [certificat...arency.org]
It uses an append only public log, similar to Bitcoin transaction log to make certificate information public.

This has started at least two weeks back (1)

Anonymous Coward | 1 year,28 days | (#44968061)

I don't know what you mean by "this week".

The whole chain for all G services is in havoc for at least two weeks. Starting end of last week there's a mass roll-out of new certs. Everything is changing, including Google's "Google Internet Authority" cert that seems to act as an umbrella for the end-certs and used to be the one thing to use for cert pinning. It's now "Google Internet Authority G2".

Cert Patrol is flashing warnings as crazy those last weeks. Got me on high alert the first couple of times.

It is supposed to change (1)

kasperd (592156) | 1 year,28 days | (#44968073)

Certificates have an expiry date. They are supposed to be changed before the expiry date is reached. On a well managed system, you'll never see a certificate which has less than a week left of its validity period. Once the certificates are changed, it should be considered best practice to rotate the server key as well, so the new certificate will always be signing a different key from the previous certificate.

It would be nice to have more information to verify the correctness of the new certificate than just the existing CA certificate chain. I would like to see a small extension to SSL where the server can tell the client that any new certificate will be signed using the current certificate. When the client is told that, it can cache the current certificate and warn the user if it sees a new certificate lacking a chain from the old to the new certificate.

SSH warns of changes, why not HTTPS (and others) (2)

FlameWise (84536) | 1 year,28 days | (#44968079)

I always wondered why SSH made just a fuzz about storing a site's certificate and warn of changes, but didn't put such a great emphasis on verifying host names or certification chains, but almost every other channel will just happily and silently accept a modified certificate.

Replacing that "This certificate is self-signed!" pop-up with a "This certificate is new or changed, please verify this MD5 hash on a trusted website: XX-YY-ZZ!" would probably increase security by an order of magnitude.

Also do this for background operations, like operating system fixes, virus scanner updates and may even MD5 downloads.

Re:SSH warns of changes, why not HTTPS (and others (1)

gweihir (88907) | 1 year,27 days | (#44968249)

Simple: SSH has never had its certificate system compromised, because it is de-central and requires individual approval anyways. The X.509 certificate system SSL uses is centralized and was likely compromised from the very start. So why warn users?

Re:SSH warns of changes, why not HTTPS (and others (1)

MrMickS (568778) | 1 year,27 days | (#44968369)

I always wondered why SSH made just a fuzz about storing a site's certificate and warn of changes, but didn't put such a great emphasis on verifying host names or certification chains, but almost every other channel will just happily and silently accept a modified certificate.

Replacing that "This certificate is self-signed!" pop-up with a "This certificate is new or changed, please verify this MD5 hash on a trusted website: XX-YY-ZZ!" would probably increase security by an order of magnitude.

Also do this for background operations, like operating system fixes, virus scanner updates and may even MD5 downloads.

Given that certificates expire, often yearly, do you really think that this would be a useful thing to do? Think about it for a minute...

The majority of people don't know much about certificates other than the nice little GUI change to show that a site is validated ok. If you start popping up dialog boxes telling them that a certificate has updated at fairly regular intervals what are they going to do? Check the certificate to make sure its valid, or just click the box away? If people get used to getting a message about certificates that basically says everything is ok there is more chance that they'll accept a true certificate warning message and end up compromised.

What happened to certificate stapling? (4, Interesting)

diamondmagic (877411) | 1 year,27 days | (#44968205)

A few months ago, Google removed the ability in Chrome to staple a TLS/SSL certificate to your DNSSEC-signed DNS records: https://www.imperialviolet.org/2011/06/16/dnssecchrome.html [imperialviolet.org]

It was finally a way to get an HTTPS secured website without needing to go to a CA. And they removed it.

I just thought they were being incompetent as they usually were, but now I can't help but wonder if the NSA got on their backs about not being able to sign their own replacement certificate...

Re:What happened to certificate stapling? (0)

Anonymous Coward | 1 year,27 days | (#44968397)

ICANN runs under contract to the US Government. Surely the NSA would be able to demand the DNS root keys and/or the keys for major TLDs if they wanted?

Re:What happened to certificate stapling? (0)

Anonymous Coward | 1 year,27 days | (#44968577)

ICANN doesn't run the root, the root operators do. And the root operators work for a variety of governments, private companies and public institutions. So the pressure would be on all those. That's not a recipe for a secret conspiracy, too many people.

But even ignoring that, the nature of a public key infrastructure is that for a cheat to work you have to provide evidence that you're cheating.Your fraudulent certificate is proof that you cheated which can be published by anyone and is irrefutable. For example when a major CA lent their CA cert to be used to produce fake site certs they _unavoidably_ proved they had done that, people could say "Here's an example of the fake site certs they produce" and nobody could doubt it was true. The CA didn't bother denying it they had to immediately begin apologising and so on.

A DNSSEC hack would produce certificate chains showing "somebody" made this fake cert using the real DNSSEC root keys. Irrefutable. So that's not the sort of the thing the NSA would want to do because it burns your bridges. Do it once, it works. But you don't get to do it again because now everybody knows.

Re:What happened to certificate stapling? (1)

Anonymous Coward | 1 year,27 days | (#44968709)

well, one would think that putting backdoors and covertly asking companies to collaborate on stasi-like activities would burn the bridges, but seems to be working pretty fine.

Re:What happened to certificate stapling? (0)

Anonymous Coward | 1 year,27 days | (#44968785)

The reason you've seen stories about this stuff but no irefutable proof is because there isn't any such proof. For a DNSSEC fake cert attack on the root the proof would be littered everywhere.

That scene in Rainbows End where they revoke the root certs for a major world bank to shut down Rabbit? That's the kind of deal. You can do it once, everybody will know you did it (though they may not know why) and it had better work. Rabbit of course doesn't go away, not quite immediately and not quite at all.

Re:What happened to certificate stapling? (1)

heypete (60671) | 1 year,27 days | (#44968655)

Possibly, but the creation of the DNSSEC root keys was done completely in HSMs in a ceremony [icann.org] that was observed by many people from all over the world. No copy of the key was ever made outside an HSM.

The HSMs are stored in secure facilities and their disappearance would almost certainly be noticed.

Transferring the encrypted keys to another HSM is only possible if you get a quorum of people to approve such a transfer. Compromising sufficient people to do this would almost certainly be noticed, and many of the people are from outside the US.

The NSA could certainly steal (or legally compel the handover of) the HSM and try extracting the keys by taking apart the HSM, but the devices are tamper-resistant and would likely zeroise themselves prior to giving up their secrets. Even if they did succeed (the NSA might have some technique for doing so), it would be an expensive operation, technically challenging, and unlikely to be done in secret.

Is it possible? Sure. Is it likely? No, not really.

Re:What happened to certificate stapling? (0)

Anonymous Coward | 1 year,27 days | (#44968825)

Would it justify the effort? Hell, yes. I assume the NSA has had copies of these keys since before the root certicifates were ever used.

Twitter, too (4, Interesting)

Lincolnshire Poacher (1205798) | 1 year,27 days | (#44968227)

Another one that Certificate Patrol has flagged inthe past week is *.twimg.com, which appears to be a mess of certs from different CAs.

One subdomain ( s0 ) has switched from a DigiCert EV wildcard cert to a Verisign per-subdomain cert.

Another has gone from Verisign to Comodo.

Annoyingly twimg.com seems to be embedded across the Web...

I've been rejecting them all, given that Twitter provide no information on their site as to whether this was a planned change.

I can still read... (3, Funny)

candlebar (2042064) | 1 year,27 days | (#44968565)

I can still read your email. It hasn't changed.

Lots of talk about MITM and complicit government (1)

spottedkangaroo (451692) | 1 year,27 days | (#44968893)

(s)

Little if any talk about http://convergence.io/ [convergence.io] — watch the linked bulletproof youtube about why SSL certs are so broken and why this package would be so awesome (if popular).

Don't panic! (0)

simplypeachy (706253) | 1 year,27 days | (#44968935)

"Verify" that your browser's SSL is secure? Uh, user, you don't seem to understand. We'll look after that. Go back to browsing, now. That's a good user.

Go4t (-1)

Anonymous Coward | 1 year,27 days | (#44969019)

GoalS. It's when another folder. 20 time I'm done here,

SSL? (0)

Bing Tsher E (943915) | 1 year,27 days | (#44969047)

I use pop.gmail.com to connect, and seldom use any other logged-in google services. I make a point, even, of not storing 'logged in' google cookies in the browser I use.

Sylpheed [sraoss.jp] is a great email client. The web is for web browsing, not ads alongside your email messages.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?