Google researchers say they've devised a way to significantly reduce the time it takes websites to establish encrypted connections with end-user browsers, a breakthrough that could make it less painful for many services to offer the security feature. What's more, the technique known as False Start requires that only simple …
"If it ain't broken..."
"...don't fix if".
I've got a bad feeling this may lead to significant increase in bugs allowing for session hijacking.
Don't be so demanding
Google was sending their auth tokens in cleartext for nearly 1 1/2 years, why worry about those things.
I'm surprised haven't simply replaced SSL with ROT13, that would have improved performance by at least 99%.
This idea of security from SSL is pretty absurd. Everybody knows it's broken from top to bottom. Even if you trust verisign (what exactly is their policy for dealing with government requests?), who the hell are turktrust and why should I trust them to sign things?
PKI is broken to the degree that if 100% of the sites out their enforced SSL the data might as well be sent in the clear anyways.
That's the reality. 3 cheers for a false sense of security.
There are a lot of problems with PKI, a hell of a lot. But it's still better than nothing at the present time.
I fully agree that browsers now ship far too many 'trusted' roots, however there is currently a reasonable expectation that the nerd sitting at the next table at the coffeeshop is probably not going to be able to silently hijack everything you do with a browser plugin. This day may come, but we're not there yet.
PKI is not the same thing as SSL. You appear not to know the difference.
It's nonsense to say "PKI is broken to the degree that if 100% of the sites out their enforced SSL the data might as well be sent in the clear anyways."
If you work at an ISP, and I connect to gmail unencrypted, you can read my emails, if you so choose.
If you work at an ISP and i connect to gmail over SSL, you cannot read my emails.
Saying otherwise is simply untrue. Saying data sent in the clear is the same as data sent over SSL is equally insecure is just nonsense, and is either hyperbole, or you don't know what you're talking about.
Umm, no ?
"If you work at an ISP and i connect to gmail over SSL, you cannot read my emails."
'Course I can. You ask for GMail's certificate, but I send you ours instead (setup to say it's for mail.google.com) and then decrypt, read, encrypt and forward the connections in both directions.
There are a few small niggles (like having to install a new root CA into your machine for you) but it's easy on a home machine and trivial in a work environment.
@Tom Chiverton 1
I'm sorry, but do you honestly believe that SSL cannot protect against a man-in-the-middle attack!? It's one of its main aims!
Your scenario fails because the ISP server cannot authenticate as my computer with the gmail server, nor as the gmail server with my computer. In other words, both my computer and the gmail server will know that someone has tampered with the communication.
For your own sake, please do some reading on the theory behind security protocols.
Honestly, good luck installing that new root CA into my machine for me. I really fancy your chances.
You've entirely missed the point incidentally.
@ Tom Chiverton 1
- LOL - That's like saying I can get into your house by smashing down the door, fitting a new one with a lock I have a key too and slipping a copy of this new key onto your keyfob and you being none the wiser.
Incidentally how do you propose sneaking this new certificate on to the ACE, CSM, SSLSM or whatever it is in the ISP that is doing this SSL termination? These things are behind locked doors and razor wire, remote access is controlled by SSH, login is controlled by TACACS+ and you'll need a network engineer with CCIE to even know how to attempt it providing (s)he does manage to gain access. Any changes to the kit will result in a SNMP trap being sent out to change control who will cross reference it against any planned changes. If I were to make any unauthorised changes I'd get the sack. - Are you saying that this level of control doesn't happen in ISP's or are you just simply unaware?
Oh and by-the-way, how do you get the key into my pocket^H^H^H^H^H^H I mean your custom CA onto my PC without the browser flashing red alert and all the hooters going?
SSL Man in the Middle
Ain't that hard to do SSL MITM. Y'all might want to take a look at SSL Strip
But why did the specification state two round trips were required in the first place? Have they in some way potentially compromised the setup? I have no knowledge in this area and would be interested in finding out from someone who deals with this for a living as it does sound a little like "our engineers did this and it may weaken things but at least you then think you're safe but, shit, we saved some overhead"
Update to previous message
I *think* they just left the cert authentication bits out of their "False Start" TLS handshake diagram, instead of skipping it durng False Start handshake. But here's the kicker for me -
"Note that the TLS client cannot infer the presence of an authenticated server until all handshake messages have been received. With False Start, unlike with the default handshake behavior, applications are able to send data before this point has been reached"
"the security goal is to ensure that if anyone at all can decrypt the application data sent in a False Start, this must be the legitimate peer: while an attacker could be influencing the handshake ... the attacker should not be able to benefit from this. "
So TLS False Start allows some application data to be sent before full authentication has been assured, but an attacker shouldn't be able to get at it. As yet I don't understand what they're doing in-depth enough to say if this leaves security holes. However, the idea of sending data before the handshake has been properly authenticated is a weird one and as I said before, I'd be really interested to get the insight of one of the hardcore SSL hackers like Mr Marlinspike.
I've just started reading the draft paper
It eliminates the certificate exchange steps.
I haven't finished reading the paper yet so I'm not sure how they justify this, but so far it's not sounding like a great security move. It uses a mechanism that seems to be related to resuming dropped connections.
Whilst I do understand the protocol pretty intimately, I'm no security researcher. I wonder what Moxie Marlinspike will make of it....
Sure you're reading the right paper?
False start doesn't eliminate the cert exchange. Perhaps you're thinking of session resumption aka "abbreviated handshake" or maybe even the "snap start" proposal submitted about the same time.
"the idea of sending data before the handshake has been properly authenticated"
"the idea of sending data before the handshake has been properly authenticated is a weird one"
Yep. It's only safe in certain cases. For example, when the client has received and already fully validated the servers cert and is encrypting the secret session key to the legitimate server's public key. This is a situation that does commonly happen in practice, so we might as well take advantage of it.
Of course, more moving parts always provide opportunity for subtle screwups on the implementation side. The major browsers will get it right though.
In a nutshell
Basically this approach can only be used if: 1) the client and server use a specific type of cipher (symmetric, strong keys - 128bits and up) that has been white listed for false starting. The "smartypants"ness is that rather than waiting for the second round trip to finish before sending application data, some initial data may already be communicated immediately after the first step. The second round trip *still takes place*, but it is possible to already do things while this happens, even if authentication may end up failing. The speedup is only cosmetic in that the user will feel things are a lot faster, simply because now "something happens" a few tens or hundred ms earlier than before, depending on network lag, and that difference is crucial. It's literally like a false start - it gets things up and running, but only in a way that lets the client/server cut things off safely if it turns out that one of the parties should object to the start. Worst case, the user still gets an authentication error, in pretty much the same time he or she gets it now. Better case, it no longer feels like you're constantly waiting for SSL authentication to finish.
And of course, the proposal is pretty clear in pointing out that it only makes sense under rather specific conditions. Both clients and servers must make sure not to send compromising data after the first, but before the second round. Then you might as well not bother with SSL at all.
Mark 65: The intent of the SSL/TLS spec is to allows for a wide variety of parameters (which cipher, bits of strength, hash function, etc.) to be negotiated during the initial SSL handshake. In many cases, it really is critical for security to ensure that all the messages are received and fully verified by the other side before sending any protected data.
But some Google engineers realized that in some very common cases the browser can, without any loss of security, go ahead and begin transmitting the request "GET /index.html ..." before he actually receives the final verification message from the server. It turns out that most servers don't even realize the browser is taking this shortcut and so it's serendipitously backwards-compatible.
Section 6 http://tools.ietf.org/search/draft-bmoeller-tls-falsestart-00 has the nitty-gritty details about the security if you're interested.
It really is a small change, but it can save (literally) the delay of a packet traveling halfway across the world.
"It really is a small change, but it can save (literally) the delay of a packet traveling halfway across the world."
I'm prepared to wait for 250 ms for my lolcat.
Starting to become clearer
If it is doable in a secure way I'm guessing the real benefit is in the mobile arena where you can (thank you Oz providers) get ping times of the order of 1.5s so a 30% saving then becomes more obvious.
Traditional SSL handshake takes an amount of time on the order of a single packet transit btwn browser and web site. This is perhaps around 100 mS (pinging theregister.com from western Canada).
False Start might cut that down to 70 mS - not exactly a revolution! Can *you* see when a page loads 30 mS faster? I cannot.
Try it from China
Or Aus. Or any country where the RTT will be in the order of 0.5 seconds.
missing the point
Duh man. This delay is per packet. So multiply that 30ms by say 100000 packets a typical web site page uses to load and you have a significant delay.
Who missed the point?
The delay of latency may be for every packet, but this improvement only saves one round trip when an SSL connection is set up. That does not happen for every packet.
Mostly obscure sites...
But I did spot cisco.com
So they'll updating the error message then?
"There is a problem with this website's security. We recommend that you do not proceed (sorry about any of your data we already sent to it on the assumption it would be OK, hope none of it was important.)."
What we need to do is to have a standard DNS record for SSL keys.
With DNSSEC implemented you have a full trust relationship (to your DNS root provider), and there is no need to have these third party certificate signing authorities...
Cant help but think that if the standard says 2 and 99% of the web works with 1... then 99% of the web ain't working correctly. I'd also assume that the 0.4% (5000 sites) that do work are probably all using the same/only software that works properly.
What are Google really up to?
@"Those sites have now been compiled into a manageable list used to turn off False Start when they are accessed in Chrome."
So how often is Chrome dialing home to update this list? Does Google for example get asked about each SSL connection we wish to make and to what website?
Whats the Google business angle? ... they are always looking for a way to help their business, so is this simply part of their play to pretend they care about our privacy, now various privacy groups are starting to have more progress in looking into what Google are spying on. They wouldn't want a government to force privacy onto them, so this and other Google news this week looks like placating Google privacy concerns.
So what are Google really up to?
Re What are Google really up to?
Google want to improve the experience with "cloud" apps, thereby increasing the time people spend online, or using Google apps. As always, they want to get more eyeballs on more adverts for longer.
If Google wants to improve...
.. the experience of using Google Apps, they should throw them away and write something usable. Messing around with security protocols to give a 'perceived' performance boost - and labeling those servers that did not allow the circumvention of the protocol as 'failures', is mere FUD during their current 'We Love Privacy (tm)' publicity campaign.
When was the last time someone here decided not to enter their credit card details, view a bank statement, or read an email - because that 'pesky SSL is too damn slow' ...?
'pesky SSL is too damn slow'
End users might not care about the SSL overhead, but the person running the web server that they're connecting to does. That's where the benefits of this change will be felt.
I don't understand the technology, but,
I'm pretty sure that a connection authentication/encryption system where the word "false" appears in the name has some 'splaining to do.
They maybe could call it "double" something - it doesn't matter what - such as "double helix", If it isn't taken. You could make a case for that. Another offering: Twince. Google it, it's really odd. I am not taking responsibility for the results, but what Google says that they are is excitingly diverse. This page will probably soon be amongst them.
Actually it seem that "twince" is often used to refer to "two children born from one pregnancy" - but a lot of other things as well, and some people don't even have a meaning for it, they just want you to search for content about it on, or through, -their- web site.
Some 'splaining, with a side of speculation and extra napkins.
Robert Carnegie: "I'm pretty sure that a connection authentication/encryption system where the word 'false' appears in the name has some 'splaining to do."
Heh. Yeah, I didn't catch the reference at first, but somewhere someone pointed out that it's like a "false start" in a race: one of the runners may have "jumped the gun" and so they have to reset the whole thing. This change enshrines the practice of the client browser jumping the gun a bit, but he almost never gets caught doing it.
By doing so, it may be possible for the bad guy to see some *encrypted* data that he otherwise wouldn't be able to see. The key to this not being a security problem is to prove that the bad guy doesn't learn the key to decrypt this data. This is done by strictly limiting the circumstances under which the false start shortcut is performed to those where the client is careful to send the decryption key only to a server certificate which has been properly validated.
OffBeatMammal: "I'm wondering (without knowing too much about this) what the ramifications are to server and cache configurations?"
The server will see 3 or more SSL records in one TCP packet where before they had been two separate packets, but TCP packet divisions are supposed to not be meaningful anyway. Other than that, I don't think there are any ramifications for the server side.
OffBeatMammal: "As more and more gets pushed to SSL by default (brute force rather than smart security) wil we just push the latency and load to other parts of the network?"
Count me as someone who thinks using SSL everywhere *is* smart security. But this minor change doesn't require anyone to process anything he wouldn't otherwise have needed to process. In fact, by reducing the overall amount of time that request is in the system processing, we might expect it to provide a small improvement in throughput.
knock on effects?
I'm wondering (without knowing too much about this) what the ramifications are to server and cache configurations?
back in the day we used to minimise what we used SSL for because of the increased hit on the server and the fact that you got horrible messages in the client if you mixed http and https traffic ... so we had to provide origins for things like the logo on the login page which didn't need to be secure
As more and more gets pushed to SSL by default (brute force rather than smart security) wil we just push the latency and load to other parts of the network?
Maybe this would explain why I've had more problems with Chrome lately connecting to HTTPS sites.
Can't remember when it started, maybe a month or so ago.
It's definitely no where near as reliable as Safari when it comes to HTTPS.
(I use a 3g connection)
Can't login to natwest online banking anymore. Keeps refreshing itself at the https stage
So, in other words...
... this is a "it feels faster now" stopgap that for maintaining security relies on the fact that everyone is sending too much crap over http connections in the first place.
Yes, I'm sure it's very clever. That doesn't make it automatically a good idea. In fact, this sort of smartarsery usually ends up biting someone's backside. But at least they're getting a paper out of it to show off to all and sundry.
Well then. "Very nice dear, now go wash up."