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

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?"

Comments

Revocation

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[houghi]

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

[smash]

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

Re:Revocation

[Anonymous Coward]

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

[bsane]

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.

Re:Revocation

[sjames]

Or anyone the NSA might have dirt on or be able to get the kangaroo court to sign an order for.

Re:Revocation

[plover]

Have you looked at DuckDuckGo for search? Their main focus is on providing good search results with user privacy: https://duckduckgo.com/privacy

https://duckduckgo.com/
https://ddg.gg/ (shorter URL)

I switched to them as my primary search engine about two years ago, and have been very pleased. They use the Bing engine and their results are pretty good, but I find I still have to fall back to Google search occasionally. I have noted that my usage of Google has gone down over time.

Re:Revocation

[hodet]

23, pfffft. Welcome to last week.

Re:Revocation

[Mr. Slippery]

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

In case anyone doesn't know, you can turn that off. Also, I advise getting on the "extended service release" (ESR) track.

Re:Revocation

[Mr. Slippery]

They use the Bing engine

Bing is just one sourse they use of many. "DuckDuckGo gets its results from over one hundred sources, including DuckDuckBot (our own crawler), crowd-sourced sites (like Wikipedia, which are stored in our own index), Yahoo! (through BOSS), Yandex, WolframAlpha, and Bing."

I find I still have to fall back to Google search occasionally.

Use StartPage instead, it proxies Google results.

Re:Revocation

[fast turtle]

What do you mean? The NSA already signs every god damn cert issued on the net as they own the Root CA's Private key and have for some time. How in hell do you think they've managed to record the meta-data from every fscking net conversation?

Re:Revocation

[hairyfeet]

Love how I get modded down for not drinking the Google-Aid. as for DDG I have tried it and its just not that good for image searches, not as good as Bing IMHO and as a nice added bonus I get a small slice of the search revenue in the form of Amazon gift cards from Bing. I figure if they are gonna make money off my searches they can at least give me a cut, and all those $5 gift cards I keep racking up is handy for all the little things I use around the shop like CD sleeves and cables and now I have my fiance using Bing and she is using her gift cards to buy all kinds of little knick knacks.

But to the morons who claimed I must be a shill for using Bing...which part of "I use no other MSFT services" do you not understand? I have no email or any services other than an old GFWL account and since they are shutting that down I won't even have that much longer. Oh and FYI even though MSFT has claimed (and may indeed have) increased the security of IE I will NEVER use it nor will I EVER give it out to customers, its not only got a giant bullseye painted on it I have also not forgotten how badly they screwed us with IE 6. For the record i always give out two browsers to my customers and family, so that if they ever bork one they do not have to fall back on IE, it used to be Chrome and Firefox but now its Comodo Dragon and IceDragon due to the fact they have extra security options like blacklisting of malware sites and Comodo Secure DNS. Oh and they are both FOSS, source code available on their site.

Re:Revocation

[Dexter Herbivore]

Sarcasm doesn't carry over the internet... Sarcasm doesn't carry over the internet... Sarcasm doesn't carry over the internet...

I really should repeat that to myself every time I comment on a /. article.

Re:Revocation

[plover]

Think about this: those $5 gift cards are the mutually-agreed-upon price of your privacy.

If I were selling my privacy for that cheap, I sure wouldn't waste time or effort worrying about the privacy features in my browser.

Re:Revocation

[bingoUV]

Nice. But it is stupid to have a browser application having write access to its own binary / installation directory. One arbitrary code execution, even by the attacker getting lucky, means that particular user is pwned for ever.

Linux distribution method seems ideal to me - root owning firefox installation, non-root running it. Can be replicated in most OSes - just don't give write permission to the user running it. Update manually (or automatically) from trusted sources.

Re:Revocation

[hairyfeet]

WTF are you babbling about? As opposed to Google that gives you jack and shit? And why EXACTLY would I give a fuck if Bing knows what parts I buy for customers?

Lets look for the last 6 hours on my searches...shall we? I searched for a C2D as I have a customer whose LGA775 board won't take any bigger and the Pentium D he has now is a power pig, FYI I got him a nice 2.2Ghz for just $12, I did a search for some parts for my nephew, he is damned determined to have a gamer rig bigger than me as he has always had hand me downs, but I raised the little guy so I'll point him in the right direction. FYI he just ordered a Socket AM3+ board as that will hold his 925 quad while letting him go octocore later, and picked up 4Gb of DDR 3 to go with it. Finally my GF has been looking for dresses for our wedding, she wants something simple and pretty and has finally settled on this nice antique looking number.

Now why in the fuck would I care if Bing knows about those? My searches are nearly all work related and boring, so I could really give a flying crap if bing has those. All they will be able to gather from me is I like 5 string basses and i buy a LOT of compter parts...so what? Anybody who spends less than 10 minutes talking to me knows that!

Google announced this

[supersat]

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

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

Re:Google announced this

[Trax3001BBS]

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

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

[Anonymous Coward]

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

[spottedkangaroo]

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

Re:Google announced this

[CaptSlaq]

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

It's not the length but how you use it?

Re:Google announced this

[spottedkangaroo]

A key is usually an integer, or a prime integer in some manifold or group. Asymmetric crypto depends on problems being easy one way and "hard" to reverse. elliptic curves are thought to be "harder" than the usual prime factoring. So yeah. It's how you use the bits. It takes a lot smaller number to provide a sufficiently ambiguous (in the reverse) operation.

Re:Google announced this

[Bite The Pillow]

Is no one smart reading the firehose to stop these early? I dont expect editors to be generalists, but surely comments would make them reconsider posting click bait.

Expiry

[jamesh]

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

[Anonymous Coward]

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

[pe1chl]

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

[EndlessNameless]

A well-designed cluster can present the same IP address to external clients regardless of which component system is servicing that particular interaction.

Why do we trust SSL?

[JWSmythe]

    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?

[Anonymous Coward]

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?

[LordLimecat]

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?

[cheater512]

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.

Re:Why do we trust SSL?

[forkazoo]

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?

[AK Marc]

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?

[steelfood]

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?

[citizenr]

    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?

[myowntrueself]

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?

[Nkwe]

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?

[Anonymous Coward]

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?

[Hypotensive]

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?

[wvmarle]

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 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?

[mvdwege]

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?

[VortexCortex]

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.

Re:Why do we trust SSL?

[Anonymous Coward]

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?

[swilver]

Spoken like a true short-sighted authentication nut.

Re:Why do we trust SSL?

[viperidaenz]

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

Re:Why do we trust SSL?

[the_B0fh]

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?

[philip.paradis]

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?

[petermgreen]

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?

[Anonymous Coward]

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?

[philip.paradis]

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?

[Anonymous Coward]

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?

[smash]

Why forge the CA when you can just buy them?

Re:Why do we trust SSL?

[smash]

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?

[philip.paradis]

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?

[AmiMoJo]

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?

[grahamm]

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?

[wvmarle]

And to fulfil that greediness (i.e. make more money) they'll have to make sure they keep the trust.

Re:Why do we trust SSL?

[Lumpy]

Thus a fine example of why going with the lowest bidder delivers the product that barely works.
Why Government still uses this useless bidding process I'll never understand.

Re:Why do we trust SSL?

[BitZtream]

Forge the CA so you can forge the certificates to do a man in the middle, its trivial. I've done it on multiple occasions at work in order to facilitate sniffing passwords to migrate users to different a new service (say from office365 to gmail without getting everyones passwords by asking).

You only know the thumbprint doesn't match if you check it and manually record it. Your browser's checks are being processed correctly via the forged certs.

I sign our MITM certs with our domain CA, its clear that we're doing it ... if you bother to look. I'm not trying to hide it, just accomplish part of my job. Being that we're on an ActiveDirectory domain with a certificate authority, the domain cert is automatically deployed to all the windows domain PCs, all I have to do is have the domain CA sign certs for my use, and all the PCs trust it.

It requires nothing special to accomplish and is working as designed. When you're using someone else's computer, you should assume they can see and hear everything you are doing at a minimum.

And no, you have no right to privacy on your companies computers or network at work, thats what you have your own home computer and network for.

Re:Why do we trust SSL?

[Lumpy]

Getting around Comcast firewalls and other things in the corporate lan is easy. Just find out what hidden AP the IT department has their cable modem on. EVERY SINGLE OFFICE IT had their own cablemodem and typically put a hidden SSID AP on it so they can get around corporate as well. We went farther and had a separate switch and some lan drops on that cablemodem only network. Typically in the Conference rooms and a couple of the common spaces.

Re:Why do we trust SSL?

[BitZtream]

Its done because software encryption on intel/amd CPUs sucks in general, though new processors with the AES instruction will start to make SSL processing easier closer to the web server itself.

You off load the encryption and reverse proxy to dedicated hardware that has ASICs to handle the encryption/decryption process because its cheaper to buy one expensive custom bit of hardware than to buy the extra 300 web servers if you try to get them to handle 10GB of encrypted traffic without hardware encryption support.

Re:Why do we trust SSL?

[Lumpy]

Oh and the WPA2 password was typically "Comcastic"

Re:Why do we trust SSL?

[Lumpy]

So all the numbers stations out there on shortwave are all useless? That is a perfect example of Encryption without authentication.

Re:Why do we trust SSL?

[BitZtream]

SSL has absolutely nothing at all to do with authorization. It carries no authorization information.

You are confused and clearly don't understand how SSL works and what it does.

SSL works by generating a new password for a symmetrical encryption algorithm on each session. Neither end knows the password before that point, they actually generate it together based on a communication method that ensures only the end points know the password.

Because both sides generate a password for each session, if you did not do authentication, anyone could jump in the middle and generate a password with you, and then create a new session to the destination you thought you were connecting to.

Authentication uses asymmetric encryption and public key infrastructure to verify that the system you are connecting to is who you think they are and not someone else, thus preventing a man in the middle attack. No authentication, your encryption is as good as useless as it can easily be intercepted and broken over the wire without you noticing.

There is no other way to work on 'web scale' authentication of connections other than PKI. Its simply a distributed automated OFFLINE CAPABLE way of verifying authentication information. If the CA cache in your browser hasn't been compromised, the CRL url can actually disable invalid signatures as well if they've been leaked or compromised in some way.

The only 'flaw' is that you trust 3rd parties. Because you trust 3rd parties to do the verification for you, it is possible they might validate the authentication information of someone who is not who they claim (for any number of reasons ranging from hacked servers, malicious intent to court order for the NSA).

Show me a method of distributing authentication information to the entire world that works better. And no, you're silly manually verified web of trust is a stupid fucking idea, which is why no one, including firefox has implemented such a feature. Just because you're idea is stupid, doesn't mean Firefox is stupid for not implementing it.

Everytime someone says something like you, they talk about some retarded way of doing exactly what we're already doing, but requiring individual users to do 1000's of times more work.

Hell, I have at least 6 SSL certificates IN MY HOUSE accessed by probably 20 different devices. Fuck you if you think I'm going to manually input 20 digit (or longer) finger prints for all those certs on all those devices, then twice as many at work, and I haven't even started talking to Amazon and iTunes to buy shit yet.

The reason we're still using 1990s 'tech' (which it was old in the 90s btw) is because theres nothing better, contrary to what you think. Please to be shutting up until you actually understand what you're talking about. You really made it clear that you have no idea whats going on.

Re:Why do we trust SSL?

[BitZtream]

What CA doesn't sell wildcard certs now? They cost a lot more, but not that much more. Lease than the price of 5 regular certs on Thawte.

Re:Why do we trust SSL?

[the_B0fh]

I'm talking about *.com type wildcards, not *.yourcompany.com

Re:Why do we trust SSL?

[Simon Brooke]

This is a very good reason not to trust any closed source browser, actually. If the source is closed, how the heck do you know what it's doing to show you that nice, safe green password icon? Of course, actually ploughing through and understanding every line of the SSL implementation code in your browser is a lot of work and 99.9% of us haven't done it, but if there were anything dodgy going on in an open source browser it would pretty quickly hit the headlines on Slashdot and we'd all know. Of course again, you don't actually know that a browser (or any other program) was compiled from the published source code unless you compile it yourself.

Gentoo, anyone?

Re:Why do we trust SSL?

[LordLimecat]

Forge the CA so you can forge the certificates to do a man in the middle, its trivial. I've done it on multiple occasions at work in order to facilitate sniffing passwords to migrate users to different a new service (say from office365 to gmail without getting everyones passwords by asking).

That is detectable unless you happen to generate the exact same thumbprint as the "true" CA. This very article is about how some folks noticed "legitimate" but unrecognized certificates in the wild.

All it takes is a quick post to a Google Groups board (as happened here), and EVERYONE now knows that a cert was possibly forged, and they can quickly get confirmation from Google as to whether the cert you were presented is a legitimate Google-issued cert.

Im not saying it doesnt "work"; it "works" in the same vein that ARP poisoning works: You will get results, but EVERYONE will know what you are up to, and in this case it would result in the revocation or un-trusting of whatever root CA issued the phony intermediate cert.

Re:Why do we trust SSL?

[mlts]

Intel used to have an appliance that did that. You configured a private key on the device, got the key signed and a valid CA cert on it, plug the machines used for round-robin Web serving into one port, the Internet/DMZ output to another port, and let it do all the HTTP to HTTPS translating. The Web servers just saw plain HTTP coming in, and the people on the outside had everything HTTPS based.

I think HP sells something similar.

Re:Why do we trust SSL?

[nabsltd]

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.

I work in a place that has a stated "no expectation of privacy" policy, but that doesn't mean that if someone uses their work PC to purchase the infamous 55 gallon drum of lube that information is going to be posted on the break room bulletin board.

What it actually means is that if you do something illegal using their computers, then they will turn that evidence over to the authorities, or if you send "trade secrets" to somebody via e-mail, they might discover it. It also means they might monitor your usage to see if you are goofing off too much, so I'm cutting this post short. ;->

But, seriously, a company that does proxying/packet inspection/monitoring is actually in a much tougher legal situation than one that doesn't, because any information that is legally declared as "private" (like medical records) has to be kept private by the company doing the snooping, regardless of the "no expectation of privacy" statement. It's no different from the HR department seeing info about your insurance claims and not being allowed to talk about them to anyone who isn't authorized to see that info.

Re:Why do we trust SSL?

[devman]

Mozilla has a bug open about it. There has apparently been lots of discussion about pros/cons of using key continuity.

https://bugzilla.mozilla.org/show_bug.cgi?id=398721

Re:Why do we trust SSL?

[fast turtle]

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

This is exactly why I've taken the time and effort to untrust every fscking cert in my browsers store (firefox). I'll add the needed exceptions for those sites that I absolutely have to have such as my bank, any online merchant such as Newegg, a few other sites that use https to protect their users (self-signed). It's really not that big of an issue since I don't hit to many https sites in any day. IMPO, the god damn browsers would be doing us all a big service is they simply didn't trust by default any fscking certs and allowed the user to make that decision. In the case of corprate systems, that decision isn't the users to make, thus an AD can push out the needed policy and you're done.

Re:Why do we trust SSL?

[fast turtle]

The only way it compromises the company security is because the idiots didn't configure it correctly. What's needed (Yes I could be wrong) is to have a proxy server and not trust any cert except that one. It does all https connections outside the companies network. Inside any connections outside the corporate network goes through the proxy server. Push out the companies cert to all machines using an AD/Ldap server and be done with it.

Re:Why do we trust SSL?

[Sloppy]

Encryption without authentication is useless.

Is plaintext useless? We're having an unauthenticated discussion here on Slashdot right now.

Encryption without authentication is useful. It's at least as useful as plaintext (that's the lower bound, the worst possible case), except that on top of that, it has the advantage of preventing passive risk-free snooping.

That's why unauthenticated encryption should not display any warnings that you wouldn't also display to plaintext users. Any such warnings can only serve to mislead the user into thinking plaintext (where they don't see as many warnings) is safer. And plaintext isn't safer; plaintext is worse.

Nobody's saying don't authenticate. They're saying that failure to authentication still isn't as bad as the default behavior, which for some reason, doesn't show warnings every time someone loads an unencrypted page. If you can explain why plaintext users shouldn't get scary warnings, then your same explanation will work for why unauthenticated encryption shouldn't result in warnings.

Re:Why do we trust SSL?

[synthesizerpatel]

With regards to the question about becoming your own signing authority - it's not that difficult really from a technical standpoint. If you've ever generated a self-signed certificate you've satisfied the most basic mechanics of the operation.

The rub is getting your root certificate onto clients. A good example of this is the process that Microsoft requires - you must have infrastructure that meets certain criteria with regards to security (physical and digital), submit to third party auditing once or twice a year, etc etc. None of which is very difficult as long as you have the money and tick off all the boxes on the checklist.

However, consider for a moment that it's not just Microsoft you have to deal with, but Apple, Firefox, Opera, Chrome/Google, Android, Nokia, WaWei(sp?), etc.

There's no guarantee that an application will utilize an OS-wide keystore, and in some cases they don't - but ship their own list of 'trusted root ca' certs.

So with each vendor that provides an application or operating system you have to then convince them that you're (1) trustworthy (2) a big enough player that they should even bother. And even then, what motivation do they have to do YOU the favor of shipping your cert? There's more than likely for lack of a better term "distribution fees", (rhymes with payola) to get your cert out there into the world.

An alternative to this is that you get an intermediate CA certificate from an existing CA (which negates any security you would bring to the table being a sub-root to someone else who could just create a cert pretending to be you) - but there's very little motivation aside from providing a skeleton key to your certs as a root ca because if you're reselling certs that's less certs for them to sell anyway.. why would they dilute the market like that?)

Long story short - the SSL certificate business is essentially a money printing operation that if you want a slice of, you'd need to grease a lot of palms (some of which are probably ungreasable), spend a lot of money.

This will likely never change because there's no motivation for existing players to change it and plenty of motivation for them to keep it as is.

If you want the security of rolling your own keys and don't have the infrastructure to deploy them to clients through an installer (i.e. you're an online vendor that accepts 'walk-in' internet traffic) - you're screwed.

If you run your own network and want to provide SSL services without using any upstream providers - just make deployment of your cert part of machine imaging / bring-up / maintenance.

Re:Why do we trust SSL?

[JWSmythe]

Ya.. Some of what I put up earlier was so others would question it.

I posted a link in another reply about gov't entities who are root CAs. In that, if you read a bit, it shows who you have to suck up to. Firefox, to be included in Firefox (all platforms). Microsoft to be included in MSIE. Microsoft for Chrome on Windows, as it uses the OS's root CAs. Chrome on Linux uses Firefox's CAs. And I'm sure Apple for it's various devices.

I haven't looked enough to see what the Android browsers use, but I'm pretty sure you'd have to get friendly with Google for that, plus any 3rd party browser authors who use their own.

I actually wrote up a quick and dirty page about 7 years ago, which goes through all the hoops of making the key, CSR, and self-signed cert. It was mostly for me, so I didn't have to type out all the openssl commands, but it's out there for the world to use, even though they shouldn't. I see hits to it all the time, so there are people using it, which means I could have been logging their key.

That is what got me thinking about it then. Why were my employers and friends throwing money at another company for their sites, when they could throw it at me and safe a few bucks.

It's really stupid if you think about it. Why does a SSL cert cost more than a couple bucks? Even at that, they'd be making a profit. Most CAs just send an email to a pre-determined address (whois owner, root, admin, domadmin, ssladmin, etc), to "verify" it's legitimate, and then send the signed cert over to the user. The obnoxious ones that usually charge more, want the D&B number, check the state's corporation filings, require blood and semen samples, etc.

End users are dumb. Most don't even know if they're punching in their credit card info on a SSL protected page or not. There are enough that look for the little padlock to believe it's trusted, but the rare exception checks to see who signed it. Why bother, it's trusted by the browser, it must be ok. At most, a few people catch irregularities like the one in the original story, and make noise about it. Do I care who signed Google's SSL cert? Not really. All that I've learned from the story is that Google might use different certs on different servers. That or the author was caught in a MITM attack and actually noticed it. .. and for giggles, I just went to my bank's web site. I'm replacing the bank domain name with "[mybank]" in this, and account access as [private.mybank].

https://mybank.com/ has a regular SSL cert for *.domain.com . Ya actually "domain". It immediately redirects to the next one.

https://mybank.org/ is a EV cert, signed by COMODO CA Limited, with a SHA1 fingerprint ending in 46:F6:C3, with an alias of www.[mybank].org

https://private.mybank.org/ is an EV cert signed by COMODO CA Limited, with a SHA1 fingerprint ending in 3C:8C:CA

That seems strange to me. They bothered to alias [mybank].org and www.[mybank].org, but didn't add the alias [private.mybank].org or [mybank].com. Well, whatever floats their corporate boat.

Re:Why do we trust SSL?

[psydeshow]

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.

Well okay, but someone could build a *much* better version of that. And mirror it out to other sites. How do you know you can trust the certificate of grc.com?

But as a proof of concept for what all secure site operators and their Certificate Authorities should already be doing, yeah.

Re:Why do we trust SSL?

[psydeshow]

Oh, and I get it now, duh. The idea is that if GRC's server sees the same fingerprint you do, then you're good. Nice hack, and something you could do yourself with your own cloud server.

But what if it doesn't, and the reason is that Google is using different certificates for different regions?

Re: Why do we trust SSL?

[philip.paradis]

The method you've described for determining trustworthiness is worthless with self-signed certificates that you haven't already verified out of band (or chosen to trust the local signing CA for the cert) or in cases where the chain of trust for a certificate has been compromised. The people operating the shop on East Street could be honest merchants, and without being able to fully trust the PKI chain that verifies exactly who you're speaking to, a man in the middle could silently intercept (and potentially modify in transit) every byte of your communications with the East Street shop. After you've transmitted your credit card number, billing address, shipping address, etc, the MITM could simply log that data for later use.

A well known tactic of skimming/carding operations (both online and at brick and mortar stores) is to capture cardholder data and sit on it for a few weeks or months, then sell a large batch of such data to other criminals. Months down the road, unless you've used a unique card number everywhere you've shopped, you're going to have an extremely hard time determining where the compromise originated, and all the while the East Street merchant did nothing wrong.

You should care very much whether or not the web shop I'm connecting to is on East Street or West Street, and you should do your best to research merchants before transacting business with them. The usefulness of "web of trust" models is best realized under circumstances where groups of people with an interest in transacting such business communicate with one another regarding the trustworthiness of those they wish to do business with, along with those responsible for ensuring the cryptographic integrity of such communications.

Re: Why do we trust SSL?

[philip.paradis]

This is a good idea.

Re: Why do we trust SSL?

[philip.paradis]

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

I find that many ACs tend to be more interested in their egos than signed-in users, especially the ACs that habitually check for replies to their anonymous posts.

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.

You must have missed the bits about the absolute importance of determining who you're talking to the first time you make a connection.

(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?)

You seem to be placing an inordinate amount of trust in network operators, trust which is sorely misplaced, as I've seen firsthand. You've also handily demonstrated an utter and complete lack of understanding of how PKI encryption operates.

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.

If you think only large projects run their own CAs, you're smoking some strong stuff. Every single employer I've worked for operated a CA for both internal and external purposes. I happen to operate three for various purposes. Be sure to inform your forum members that you don't shit two shits about their privacy.

Re:Why do we trust SSL?

[EndlessNameless]

The contracting office is staffed almost entirely by contract-law lawyers.

They often have no means of assigning value to the proposals submitted for review, so they accept the lowest bid with an overall "barely meets requirements" rating from the technical reviewer.

Re:Why do we trust SSL?

[EndlessNameless]

> Im not saying it doesnt "work"; it "works" in the same vein that ARP poisoning works: You will get results, but EVERYONE will know what you are up to, and in this case it would result in the revocation or un-trusting of whatever root CA issued the phony intermediate cert.

If he is the domain administrator, his users probably cannot revoke or remove the root CA he created. He could even prevent them from seeing which CAs are trusted at all.

His claims are completely accurate for his proposed environment, which is a fairly typical corporate setup.

Convergence and Perspectives

[magic maverick]

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

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]

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

Re:Convergence and Perspectives

[BitZtream]

The Monkeysphere Project tries to solve the same problem by using the PGP web of trust model

No, lets not.

This is a horrible model to try and use on a global scale. Crowdsourcing is not an authentication solution, its a stupid idea. Theres a reason PGP has never taken off outside geeks validating their linux binaries ... because someone cares about the linux machine running in your basement.

When will you guys get it through your heads that 'distributed everything' doesn't work. Central authorities are needed to mediate and ensure everyone is on the same page. Central authorities also come with the risk that they can be compromised, but its far easier to deal with one compromised CA than several billion.

PGP has all the disadvantages of using CAs, none of the advantages, and additional disadvantages, mostly in that it requires users to make decisions they aren't qualified to make, which they could do currently IF THEY WANTED TO. They don't.

Re:Convergence and Perspectives

[Sloppy]

When will you guys get it through your heads that 'distributed everything' doesn't work. Central authorities are needed to mediate and ensure everyone is on the same page.

Those central authorities are welcome to join in, and become highly valued nodes in the WoT.

Central authorities also come with the risk that they can be compromised, but its far easier to deal with one compromised CA than several billion.

Aha, now I get it... could it really be this simple? Are X.509 advocates merely bad at math? The terms in your risk assessment formula are wrong.

If a signer has a probability p of being accurate/trustworthy, then the chance of its attestation being correct, is p. That's how X.509 certs work and of course you understand that very well. Cool. With PGP, if signer1's probability of being accurate is p1, and signer2's probability of being accurate is p2, then the chances their joint attestation of an identity is accurate, is 1-((1-p1)*(1-p2)). Dude, that's a number which is greater than either p1 or p2.

For example, say you think it's 90% likely that Verisign is telling you the truth about a key belonging to a certain website. They're the one and only signer for some website (because one signature is all this shitty tech can handle), so you think it's about 90% likely you're talking to that site, and 10% likely you're talking to the NSA. If that's your estimate of Verisign's reliability/trustworthiness, then 90% is the best you can do with that tech.

Now let's say we upgrade from that garbage to 1991 technology: the PGP WoT. Suppose Verisign and CNNIC have both signed something, and you think Verisign is 90% reliable and CNNIC is 60% reliable. (Those sneaky Chinese bastards!)

You're 1-( (1-0.9)*(1-0.6) ) = 0.96 , that is, 96% confident that you're talking to the website you wanted to, and 4% worried that you're talking to someone who is involved in a join US-China conspiracy (which, now that you think of it, is less than 4% likely to really occur). You have just wiped the floor with X.509's security performance.

Suppose I signed it too. You don't know me. While it seems absurd at first that I'm less trustworthy than the Chinese government (they're known badguys; I'm merely some internet asshole) at least you know something of their loyalties or lack thereof, and very little of my competence and motivations. It's reasonable to assume I am probably more likely to conspire with your adversaries than they are. Some guy with US government might be holding a gun to my head, right now! So you decide to only trust me 1%. Ok. Guess what? You can work with that!

Now my super-weak signature is on there. You trust the identity 1-( (1-0.9)*(1-0.6)*(1-0.01) ) = 96.04%. My super-weak nearly-completely-untrusted attestation made it stronger.

This is why were totally wrong when you said one compromised CA is easier to deal with than a billion. A billion compromised CAs are easier to deal with than one. Distributed authentication is more fault-tolerant, and we're now in a situation where the mainstream finally "gets it" that the faults really do occur, rather than it simply being a tinfoil hat thing that cypherpunk SciFi authors pretend to worry about. X.509 is based on the idea that Verisign is telling you the truth 100% of the time, and cannot model the idea that you think they sometimes fail. PGP, on the other hand, is based on reality: that grey world where sometimes things work and sometimes they don't, where you sort of trust some people some of the time, etc. You know, that world that you actually live in.

Detecting Certificate Change

[seawall]

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

[wvmarle]

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

[Foresto]

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.

You don't know

[AHuxley]

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
Welcome to the gift of free ENIGMA encoding with another rotor?

Certificate Transparency

[goddidit]

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/
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

[Anonymous Coward]

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

[kasperd]

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.

Re:It is supposed to change

[sayno2quat]

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.

I've not heard this before. I'm curious to why this would be considered best practice. What reasons are there to cause one to want to generate a new key instead of reusing the old one?

Re:It is supposed to change

[kasperd]

What reasons are there to cause one to want to generate a new key instead of reusing the old one?

For the same reasons that you would rotate passwords. It is just a precaution in case it accidentally was leaked. When changing certificate anyway there is no inconvenience to the users from replacing the key, so you might as well replace it. It would for example help a bit in case an old backup of the webserver had been leaked. The difference in security is minor though, there are much greater threats from insecure CAs.

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

[FlameWise]

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.

What happened to certificate stapling?

[diamondmagic]

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

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?

[heypete]

Possibly, but the creation of the DNSSEC root keys was done completely in HSMs in a ceremony 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?

[Anonymous Coward]

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?

[swillden]

Unless the NSA has worked with the manufacturer of the HSMs to install back doors. A few months ago I'd have pooh-poohed that notion. Today... my team and I are actively thinking about what we can do to mitigate that risk with respect to the commercial HSMs we use.

Re:What happened to certificate stapling?

[swillden]

It would be sufficient if the HSMs contained a little NSA feature that makes the NSA's work easier.

Indeed. A very obvious approach for cryptographic keys generated inside of HSMs is to reduce the entropy. Suppose for example, if you ask the HSM to generate a 128-bit AES key and it provided one selected from a set of 2^50 possibilities. It would be virtually impossible to detect that the effective keyspace is dramatically reduced, but if the NSA knows what the 2^50 possible keys are, they can brute force the space and decrypt your data.

There are lots of other subtle tweaks that could dramatically reduce the security in ways that are almost impossible to detect.

Re:What happened to certificate stapling?

[swillden]

Well, for one thing, your HSMs are never anywhere near a network, so there's no possible way to back door in to them without gaining physical access. Then it's just a matter of making sure they stay physically secure.

Unless the "back door" is something like reducing the randomness of key generation, or leaking bits in IVs, or... and many HSMs that serve on-line systems are on networks. They should be as isolated as possible, and of course well-secured physically, but nothing is perfect, employees with physical access can be bribed or coerced, etc.

If you assume your opponent has the resources of a major government agency, and may have colluded with your vendors, securing your data is a really, really hard problem. It's not impossible if you have the resources, but it's far from easy.

Revocation --- or Redundancy?

[ron_ivi]

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?

[the_B0fh]

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?

[petermgreen]

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?

[TheRaven64]

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?

[sjames]

And just to be sure, we can threaten them with pointy pillows.

Re:Revocation --- or Redundancy?

[Ash-Fox]

I wonder why HTTPS stuff can't require *two* certificates that validate.

Actually it can, it's called a client side certificate, I have done it in Apache. It requires you generate a certificate for the client, who has to then import it to their browser.

Even better if one of those can be a self-signed one.

You can choose whatever certificate trust chain you want.

Re:Revocation --- or Redundancy?

[Anonymous Coward]

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?

Fuck it...we're doing *FIVE*.

Re:Revocation --- or Redundancy?

[Prehensile Interacti]

These are similar thoughts to my own. It needs to be about a web of trust, and it might just work.

If more parties are able to come along and say "I trust all these authorities" when it comes to doing business with me, this is the paradigm shift. I don't believe that there is *an* independent authority, I believe we should elect to allow *multiple* authorities to rate the trustworthiness of a certificate.

At the moment, outside of high-end corporate who roll their own, it is the operating system provider making that trust decision for all of us in their selection of root authorities. Now Microsoft, Google and Apple are all on the PRISM slides, and Linux is probably compromised in its own way - not one of them do I want to be the sole gatekeeper of my trust.

So, I believe that the 1st group that should be brought into this system are the banks. This is the group that has the most to lose financially, if you're the victim of fraud. Specifically *your* SSL, should be vouched for by *your* bank - with the condition that the online fraud protection on your bank account is only effective, if you were entering your card details in an SSL session they vouched for.

Now I see a future where we all allow multiple people to vouch for the goodness of certificates and authorities (I think this extends to public keys too) - particularly our social network. Anyone we trust to vouch may approve or *disapprove* any cert. Any time we do anything requiring crypto trust, we should be able to see how all the people we trust feel about it. I have a number of friends I'd really trust to always do a secure key-exchange; I'd boost their scores. Beyond that, the wisdom of crowds is a not a bad fallback.

We have to understand that trust is on an analogue scale. For many things it's fine that we don't have close to 5x 9s of trust. But when we do need to be really certain of who's on the other end, we should be able to push into our social network and see who will vouch for the other parties public key / certificate.

Re:Revocation --- or Redundancy?

[Jesus_666]

Ah, the Gillette Encryption Standard. I'm just waiting for browsers to start supporting SSL Fusion Power Stealth.

Re:Revocation --- or Redundancy?

[sonamchauhan]

Hmmm. Client certs are used for authentication of the client to the server (the server also has to import the clients public vert). If there is a successful MITM attack, the client will simply authenticate to the wrong server.

Re:Revocation --- or Redundancy?

[Sloppy]

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

It sounds like he does indeed know how it works very well. It's actually a great idea, which is why PGP defaults (I think) to requiring about three "moderately trusted" CAs to agree, in order to confirm an identity. Upgrading from our current luddite stuff to gleaming new 1991 tech would be fantastic, and is pretty warranted, when you think about how silly our current situation is. Treating something like Verisign as a fully trusted introducer? ha! They're not that trustworthy, but they're not useless, either. PGP's concept of differing degrees of trust, gets it about right and would be a huge step forward.

Re:Revocation --- or Redundancy?

[sonamchauhan]

Don't let the fool trolls get to you - you have a good post.

For instance, a trivial browser-side implementation could simply check if bytes flowing in on an SSL connection (say, to https://abc.com443/ matched bytes coming in through a secondary persistent HTTPS connection (say, https://verify.abc.com443/ and that both HTTPS connections use different CA authorities.

Sure, this could be defeated if abc.com is compromised. However, an MITM attack would require two separate CA authorities to be fooled or compromised. And adding verification hosts (verify1, verify2, ...) would provide additional 'witnesses' against a MITM.

Re:Revocation --- or Redundancy?

[drakaan]

I think that while that's good, in terms of fixing some problems with SSL, it doesn't fix the problem of not being able to trust what happens outside of the SSL connection. If there's 4096-bit SSL encrypting my connection and I have multiple organizations expressing trust in all levels of the cert chain, but there's an [NSA/Chinese hacker/someother type of] connection sucking unencrypted data off of the server at the other end of the connection then who cares?

Even if you're certain who's on the other end, you can't be certain that they're not sharing your data after it's decrypted...knowingly or unknowingly.

Re:Revocation --- or Redundancy?

[TomGreenhaw]

Like razorblades - great idea! Can we make vibrating certificates?

Re:Revocation --- or Redundancy?

[WuphonsReach]

"DANE" is the RFC that is in-progress for storing SSL certificates inside DNSSEC.

Main advantage is that if ".com" is compromised, they still can't sign DNSSEC requests for ".biz". So damage (bad actor) is a bit more localized.

Re:Revocation --- or Redundancy?

[mlts]

We could assign CAs a trust factor and have multiple CAs in different geographic locations (preferably different countries) sign a key. However, this turns SSL from a PKI into a WoT (web of trust.)

Without a doubt, a well maintained web of trust is more secure than the SSL/TLS principle of "anything signed by these root certs is 100% trustworthy." However, there is the user issue. Joe Sixpack wants a green lock icon. He doesn't want to worry that CA #1 is more trustworthy than CA #2. He just wants to enter his credit card details with a low chance that it will be compromised.

Re:Revocation --- or Redundancy?

[mlts]

What can be done is to add a trust factor to CAs. Say someone doesn't like a CA out of Elbonia, they can completely nullify it by adding a trust factor of 0. A CA that someone personally runs and can vouch for would get a factor of 1.0. A CA that one is unsure about, might end up with a 0.5 for a factor. Then, there is a threshold set that if it goes above it, the site is trusted.

An example: Three CAs, trusted at 0.5, have signed a site's key. The threshold of trusting the site is set by the user at 1.2, so this causes the site to be considered trustworthy. Another way this can happen is two sites trusted at a 1.0 factor could go over.

Then, one can add distrust, where if one CA is distrusted at a -1 factor, it would take three 1.0 trusted CAs to bring a site over the 1.2 threshold.

If one wanted to get fancy, reputations can propagate between individuals which might add more weight to trust/distrust a site's certificate. A site's trust can increase over time if its certificate has not changed in a while as well.

Re:Revocation --- or Redundancy?

[Prehensile Interacti]

A good question, how can you trust the other end? This still comes down to reputation, doesn't it?

The most extraordinary thing we're seeing with the spying revelations, is the complicity of all three branches of government and the vast majority of the fourth estate in trampling all over our civil liberties. When the system of checks and balances has failed so badly, it makes it nigh on impossible to know who to trust any more except our close friends.

Now that some of the practices have got out, I'm sure the US internet providers are going to see some blow back - their reputation is surely damaged.

While previously globalisation has meant that worldwide trade had been busy merging into just a handful of players in each domain, I hope that scares like the current one, remind us of the need for bio-diversity in our corporate culture. How to enforce that happening is beyond me.

Re:Revocation --- or Redundancy?

[smaddox]

Real men certify identity the old way: a single certificate encrypted by hand. If there's no chance for a (digital) life-ending catastrophe, you're not doing it right.

Re:Revocation --- or Redundancy?

[fast turtle]

and this is why I've taken the time/effort to mark every cert in the browser as untrusted - then add exceptions for those locations I actually use.

Personally, I feel that if the god damn browsers went to the untrusted model and allow the user to trust certficates on an as needed basis, we'd be far safer then we currently are. Hell it would kill most of the ads online on any secure site unless served by the site directly because the adverts wouldn't be secure and if using https wouldn't have a trusted certi, making it easy to block any/all connections to them

Re:Revocation --- or Redundancy?

[smaddox]

There's also the issue of how to update your public key in the web of trust, if your private key gets compromised. Any mechanism you implement for doing this could be hijacked by a third party in order to change your public key to theirs, thereby nullifying the point of having multiple separate CAs.

Re:Revocation --- or Redundancy?

[the_B0fh]

Have you even tried reading wikipedia on PKI? What OP is suggesting is silly, lots of work, prone to failure, more avenues of attack, and just doesn't make sense.

Just sit down and think for a moment (it's unclear if OP is suggesting the cert, or the root cert is the redundant security, but since we have multiple root certs, that is already redundant). You need two certs. One from verisign, one from diginotar, in order for your secure site to work.

Now what? You have to track expiration, configuration and all that shit on *TWO* certs. Sure, that's not much work. For someone running a dinky website. But when you have thousands of certs (I have 10,000+ at work), now what? Managing twice that amount? Making sure everything is coordinated? And what gain do we get? Nothing.

So why do you feel it is OK to make stupid suggestions when you don't know what is going on? When you are at the hospital, do you also wander over to the operating rooms and suggest to the surgeon how they need to operate?

Re:Revocation --- or Redundancy?

[fast turtle]

Verisign Trustworthy? They're owned by the NSA and have been from the fucking beginning. It's the entire reason the damn net decided on PKI and Root CA's. Anyone remember the debate about Key Escrow? That's what we ended up with and the damn engineers were to blind to even understand that PKI is exactly that.

Re:Revocation --- or Redundancy?

[Shatrat]

You probably work with two telcom companies to make sure your website and/or company has network access

As someone who works in telecom, this is not as good an idea as you think it is. You're almost always better off buying diverse/protected service from one company than trying to use 'carrier diversity' to save your butt. Very often both telecom companies will be using the same fiber, or leasing transport capacity from one another. Example: You buy an unprotected Ethernet Private Line from Level 3, and then turn around and buy another unprotected EPL from XO. They're both unprotected linear transport, but what are the odds both carriers will have an outage at once? The answer, 100%. XO uses Level3 fiber everywhere.

Re:Revocation --- or Redundancy?

[mlts]

I wonder if this could be solved how I solve this issue with PGP keys, which can be three ways:

1: Have multiple places have the ability to revoke your cert for you, say 3 out of five people or organizations. Of course, three of these compromised could generate a fake revocation, but the data signed/encrypted by the original private key is still protected.

2: Generate and save offline revocation certificates. The only thing an attacker can do with a revocation cert is propagate it, expiring a valid key early, which can be an attack to deny access, but it would not mean they could read data by that key.

3: This is the most dangerous, and one that takes a lot of assurance to run right. A key escrow service. The good is that a private key can be recovered. The bad is that if it isn't done 100% perfectly, a bad guy can recover a key which is the worst possible thing of all worlds.

Re:Revocation --- or Redundancy?

[Sloppy]

Now think it through. If Verisign is owned by the NSA, and a Russian CA is owned by FSB, and a Chinese CA is owned by that government, and all three of these compromised CAs agree on a cert, what does it mean?

It means the cert is probably accurate, or about as accurate as you can possibly get, without going over to the server certing it yourself. If those three parties are conspiring to disrupt your Amazon order, then I'm afraid you're not going to get your package, no matter what crypto you use. :-)

Re:Revocation --- or Redundancy?

[Shagg]

Currently PKI works by deluding people into thinking that PKI works. A chain of trust is useless if you can't trust the top of the chain. It's all based on the illusion that the CAs are trustworthy.

Since CAs can (and have) been compromised before, then the only thing having multiple CAs will do is make the illusion prettier. What rule says that the "bad guys" only compromise one CA at a time?

Re:Revocation --- or Redundancy?

[mellon]

In fact something like this exists and may even be supported by your browser, but isn't in wide deployment at the moment. The way it works is that example.com goes out and gets an SSL cert for example.com, signed by some reasonable CA. example.com also configures dnssec for their domain. When you go to https://example.com/ your web browser does a DNS query against _443._tcp.example.com for TLSA records. If it finds any, it validates the cert it gets via TLS against the TLSA record; the TLSA record can specify what certs are valid, or it can specify what certificate authority key (trust anchor) is valid, and there are a few other modes. The basic principle is that you now have two paths for validating the TLS cert: the CA _and_ DNSSEC. If both validate, use the cert. If either fails, don't use it. You can read all about it here.

In addition, TLS provides for certificate revocation, so if someone generates a bogus cert and it is _detected_, the cert can be revoked, or if a key is compromised, the cert for that key can be revoked.

These mechanisms seem more likely to be useful than just requiring certs from two different CAs.

Re:Revocation --- or Redundancy?

[mellon]

It's great if you have the discipline to do that, but this is not a UI that works for people who do not understand the threat model, because they will get popups all the time, and they don't know how to check whether they are valid. So they'll just get in the habit of clicking yes. So this winds up potentially being _worse_ than the status quo, because now a bad cert will present a similar, if not the same, UI to a good cert, and they'll click through on both without validating either.

Re:Revocation --- or Redundancy?

[mellon]

Trust is not binary. It costs some effort to get a key certified for a domain that isn't yours. So a CA cert says "either this key is good, or someone spent a lot of money to compromise it." Of course, you'd much rather that it said "this key is good," but that's not what it says, and the fact that it doesn't say that doesn't mean the cert is valueless—it just means that it has limited value.

We definitely need a stronger system, but the current system is better than no system.

Re:Revocation --- or Redundancy?

[mellon]

No, worse! Let's threaten them with the round pillows!

Re:Revocation --- or Redundancy?

[Shagg]

There are situations where thinking you're secure when you're not is worse than knowing you're not secure.

Re:Revocation --- or Redundancy?

[nmr_andrew]

Sadly, I used my last mod point a few minutes ago, or I'd mod this up. If you know about a vulnerability you can take steps to stay safe.

Re:Revocation --- or Redundancy?

[ron_ivi]

What can be done is to add a trust factor to CAs.

Trust can't be a single value.

For filing my taxes, there are some CAs I trust far more than others.

For downloading movies (if I were to do that), there are also some CAs I trust far more than others -- but that set is entirely non-overlapping with that first set.

And for buying stuff with credit cards, sometimes I'd trust that first set, and I could imagine times I'd rather trust that other set.

Re:Revocation --- or Redundancy?

[mellon]

This is absolutely true. However, the typical user simply doesn't have the mental model they need to evaluate whether they are secure. A solution that gives them security 99% of the time is a lot better than one that gives them security 0% of the time. The remaining 1% could very well completely screw them, but if they were at 0%, they would be completely open to attack. Best is the enemy of good enough.

FWIW, I am not arguing that the system doesn't need to be improved. I'm just saying that throwing it out and replacing it with nothing is not an improvement.

Re: Revocation --- or Redundancy?

[jbo5112]

The problem these companies are facing is that the laws and regulations are so complex that the government can tie any company up in red tape and choke them out of business, if they aren't friendly enough towards government spying. On top of that, failure to comply with the NSA can be considered treason.

To round things off, the government make Google face charges of violating wiretapping law and charges for people being too stupid to read their terms of service.

Re:Revocation --- or Redundancy?

[smaddox]

I do like the idea of splitting revokes and reissues into two separate events. It's not foolproof, but this would give time for humans to get involved.

Twitter, too

[Lincolnshire Poacher]

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.

Re:SSL

[gweihir]

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.

Detecting Certificate Inconsistency

[thegarbz]

While we're at it some other addons like Perspectives or Convergence 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:SSH warns of changes, why not HTTPS (and others

[gweihir]

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:answer...

[GigaplexNZ]

That's an in-band means.

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

[MrMickS]

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.

Re:SSL

[myowntrueself]

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.

I can still read...

[candlebar]

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

Re:SSL

[gweihir]

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

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

Getting the fingerprint in JS

[Richard_J_N]

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

[cheater512]

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:Getting the fingerprint in JS

[Richard_J_N]

Hashing it won't help - I want to inform the user that their data is being intercepted, not that it's being corrupted.

Re:Getting the fingerprint in JS

[Albanach]

Surely if it were being intercepted, it could also be modified? If it can be modified, then they can change the javascript so as to never report a problem. Similarly for a manual check they can simply change the fingerprint you send to match the one they are using.

If they have a valid certificate and are using it to perform a MIM attack, nothing you send or receive can be trusted.

Re:Getting the fingerprint in JS

[Richard_J_N]

If we're talking about the great firewall of china, you're right. BUT most corporate proxies run fairly standard software, and only update it every few months (if that). So, there's a pretty good chance of my getting the JS through the first time, and of the vendor taking a long time to work around it (if they ever do). Yes it's cat and mouse, but there are a lot of mice with different strategies, the cat isn't very quick, and as long as the mouse gets through once, it's enough to let the user know he's being snooped on.

Re:Getting the fingerprint in JS

[cheater512]

Very hard in that case to detect someone intercepting but not modifying anything.

Best way in that case is to create a 'fingerprint' of what a corporate interception proxy is from the SSL data it sends your server.
Stuff like supported encryption standards. Not too hard if the user is using a modern algorithm but they connect with a crappy algorithm because you are actually talking to the proxy.

Re:Expiry - maybe?

[Anonymous Coward]

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: 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: 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, 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. 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... 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.

Lots of talk about MITM and complicit government

[spottedkangaroo]

(s)

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

Third Party Checker

[astralbat]

If you're paranoid about Man-In-The-Middle attacks or would just like to know whether your own corporation surveils your HTTPS browsing, you can use this checker: https://www.grc.com/fingerprints.htm to confirm whether your certificate fingerprints are the same.

Why?

[wisnoskij]

I don't believe it, what could ever possible be gained by Google compromising their email security?
We already know that all the powers that be have access to everyone's gmail account, through a Google made interface, making compromising the security irrelevant.

multiple certificates

[higuita]

It's worst than that, google and many other big sites have multiple certificates, so when you go to one of those sites you never know what certificate you will get...
install certificate patrol on firefox (and https everywhere) and you will see how easy is to change certificates in google

Re:Read their Blog - It has changed

[niaxilin]

http://pki.google.com/faq.html The FAQ for Google Internet Authority also mentioned changes coming in Q3 2013, plus a lot of other cool stuff I had no idea about.

No root CAs?

[alexo]

Is it feasible to use the web with no trusted root CAs at all?

Re:VPN that connection !

[JWSmythe]

The same still applies. Sure, you're circumventing the eavesdropping of your employer. You still have a long list of trusted signing authorities in your browser.

Firefox list

Microsoft/MSIE

Chrome

There's no good reason to believe your encryption is end-to-end safe. It's end-to-whoever-runs-the-proxy-server encrypted. Someone in your house won't eavesdrop on it, but ye olde MITM by a large enough organization can. There are some telecom providers included.

So your employer can't sniff your traffic, and you've compromised their internal security. You're safe from your desk to your home machine and that's it. I'd say you're totally safe on your computer, but as your employer could use keystroke loggers, watch your screen, and even access your files (via \\yourdesktop\C$\), the only thing you're protecting is the easy logging of the URLs you've browsed. If they're already doing deep packet inspection, either the VPN connection won't be established because VPN won't traverse the content inspector, or they'll notice massive amounts of encrypted traffic always going to the same place. So it won't work, or you'll raise red flags.

What if a government agency got in on this game? They could sign and eavesdrop without you knowing. Oh wait. They are already there.

Firefox: France, Hong Kong, Japan, The Netherlands, Spain, Taiwan, Turkey

Microsoft/MSIE: Austria, Brazil, Finland, France, Hong Kong, India, Japan, Korea, Latvia, Macao, Mexico, Portugal, Serbia, Slovenia, South Africa, Spain, Sweden, Switzerland, The Netherlands, United States, Tunisia,Turkey, Uruguay, Venezuela,

Chrome uses the underlying OS root CA list.

Any one of them can sign valid certs. For MSIE and Chrome users, the US Gov't can sign for *.google.com, and intercept all the traffic, without the need of adding any extra CAs to your browser/computer.

They should maintain a fingerprint list

[psydeshow]

Yes, there is a simple solution.

Google should post, in a permanent, obvious location, a list of the SSL Certificates they are using along with the certificate fingerprints.

This list should be mirrored by other parties and the issuing CA to prevent the problem where someone with a forged cert can post their own list. They could also mirror the list in DNS TXT records.

This should be standard for every well-known site that uses SSL, and it should be a service provided automatically by every Certificate Authority.

I'm sick to death on non-transparent CAs. Publish the certs you sign. Publish your revocation lists. Stop assuming that no one understands what you do or that you don't have a responsibility beyond lining your own pockets.