Google's Obfuscated TCP 392
agl42 writes "Obfuscated TCP attempts to provide a cheap opportunistic encryption scheme for HTTP. Though SSL has been around for years, most sites still don't use it by default. By providing a less secure, but computationally and administratively cheaper, method of encryption, we might be able to increase the depressingly small fraction of encrypted traffic on the Internet. There's an introduction video explaining it."
Firefox isn't helping (Score:4, Insightful)
Firefox isn't helping the lack of SSL on the web by throwing a ridiculous warning when using self signed certs. Browsers should treat self signed certs as 'unsigned with the added bonus that communications can't be eavesdropped' instead of freaking out that you might not know who you are talking too.
self signed certs aren't appropriate for processing credit cards... but not every site that has forms needs that... and simply removing eavesdroppers would be a step in the right direction.
Re:Firefox isn't helping (Score:5, Interesting)
"simply removing eavesdroppers would be a step in the right direction."
Yes. Whereas self-signed certs let the eavesdropper send you a certificate which makes you think your connection is secure when in reality they're listening to everything you send.
Re:Firefox isn't helping (Score:5, Informative)
Per definition, then you're more than an eavesdropper. Then you're actively intercepting and rewriting the connection, which is a lot more complicated to do in volume plus detectable by comparing fingerprints. Whereas just copying the stream for the NSA is trivial and without detection possibility, but hey pick no security because the other is imperfect.
Re:Firefox isn't helping (Score:5, Interesting)
Or distinguish between "authenticated" and "encrypted"?
Or finally admit that maybe there are more shades of grey than "secure" and "insecure" when it comes to send and fetching data over the Internet?
Re: (Score:2)
Re:Firefox isn't helping (Score:5, Interesting)
Re: (Score:3, Informative)
It works great for ssh and solved the whole key distribution problem.
It works great after the initial conection, but you're vulnerable to a man in the middle attack on the initial connection attempt. It doesn't solve the key distribution problem at all. Or did you not read the warning message that ssh prints out on initial connections? You're accepting a risk, just as there is a risk in accepting a self-signed certificate. The difference is that your average SSH user can understand the risk, whereas unless you go the extreme route Firefox has gone, the average Web user will
Re:Firefox isn't helping (Score:5, Insightful)
The point being that this is the actual security hierarchy, from best to worst:
Whereas most web browsers make it appear like this:
Any browser that warns you about self-signed certs should make at least as much of a fuss about using plain HTTP, but they don't. Firefox takes it to ridiculous extremes but they're all faulty in this respect.
And really, if browsers would save the self-signed cert and then alert me if it changes the way SSH does, then the result will be very good, nearly as good as a regular cert (and potentially even better, since there's no potential for compromising the trusted certificate authority).
Re: (Score:2)
The thinking behind the current browser behavior is that the while self-signed certs provide encryption, they do absolutely nothing to try to verify that the remote host is who they claim to be. Providing a lock symbol (which, over the years, security professionals have tried to train users to trust) when there is nothing even resembling validation does a disservice to the user. There is no need to make such a fuss over plain HTTP because users have been trained not to send credentials over plain HTTP. T
Re:Firefox isn't helping (Score:5, Insightful)
So stop displaying the lock symbol! Nothing requires you to treat "real" SSL and self-signed SSL identically. It should be obvious that the current standard approach of making them look exactly the same except for a scary warning that appears the first time you hit a self-signed site is broken. But nobody cares about doing better because it's the "standard".
Re:Firefox isn't helping (Score:5, Insightful)
aka: "Whereas having a keyed lock on your door lets a thief pick the lock and steal everything inside."
Therefore we should make it less convenient to put locks on doors.
Re: (Score:2)
Straw man: The keyed lock argument is easier to prove false, and seems naively analogous to the SSL problem.
We are instead talking about a keyed lock where I, as an attacker, can walk up to your house after you leave and use a key with a specially shaped tip to to prime the lock for accepting a new key (in addition to the old key-- this is not technically identical, but from a user interface point it is the same interaction). I can then unlock your door with my completely random key; when you get home,
Re: (Score:2)
Re:Firefox isn't helping (Score:5, Insightful)
SSL without a trusted certificate provides NO additional security over communicating in the clear. AT ALL.
Bzzzt, wrong, thanks for playing.
Yes, the man in the middle attack is very real. However, it takes a great deal more work to set up than a simple sniffer, because you have to either capture/block/proxy/rewrite packets so that each side thinks it's speaking with the other, or spoof the DNS somehow.
On the other hand, a simple network sniffer can capture almost everything send in the clear, no special network tricks needed.
Authentication requires encryption. Encryption does not require authentication, but should then be considered somewhere between truly secure and just wide open. Call it a nice-to-have that prevents casual sniffers from picking up passwords to your home server, reading your webmail, and the like.
Your assertion assumes that there are no casual crackers/script kiddies out there who won't immediately escalate to some invasive and rather difficult MITM attack, or that sniffing is not a real danger. I'd argue that 90% of the insidious activity comes from just sniffing cleartext off the wire, and that more sophisticated attacks are significantly rarer. Encrypting the over the wire traffic is a way of mitigating a significant portion of that risk.
Re: (Score:3, Informative)
Indeed. You have to press one additional key to forge SSL connections in most "off-the-shelf" sniffers. I recall doing this with ettercap many years ago.
Re: (Score:2)
However, it takes a great deal more work to set up than a simple sniffer, because you have to either capture/block/proxy/rewrite packets so that each side thinks it's speaking with the other, or spoof the DNS somehow.
The "Default Gateway" IP address allows your computer to send an ARP for your gateway (i.e. 192.168.0.1) and get its MAC address; to send a packet to be routed, it determines that the destination IP isn't on this subnet and so sets the MAC address for the frame to the MAC of the default gateway (hardware drops any frames destined for anything beyond its own MAC or broadcast), which looks at the IP address and uses that to route, setting the MAC to the next hop. There is no encapsulation of packets to rout
Re: (Score:3, Insightful)
Bzzzt, wrong, thanks for playing. I written an app that makes the process as easy as starting a sniffer, just because you don't know of any software that automates the process doesn't mean they don't exist. The app doesn't work flawlessly due to the technical details involved, but it certainly works well enough for me to watch 'encrypted' data flow just as easy as it is for you to star
Re: (Score:3, Insightful)
EXACTLY! With a self-signed certificate, there's no indication that a man in the middle attack is taking place.
SSL without a trusted certificate provides NO additional security over communicating in the clear. AT ALL.
Self-signed != untrusted, and CA-signed may not always = trusted. Why do people always seem to just assume that CA-signed/self-signed are equivalent to trusted/untrusted?
There are ways to verify certs other than having a site- (or attacker-) chosen CA sign them. For example, the Perspectives [cmu.edu] firefox extension relies on "you can't fool all of the people all of the time" rather than the "you can't fool any of these people ever" that the CA system relies on. And it works regardless of whether a cert is self-si
Re:Firefox isn't helping (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
The problem (I think) with treating self-signed certificates as 'unsigned with the added bonus that communications can't be eavesdropped' is that it would rely on site owners not asking for sensitive information while using a self-signed cert.
Most users are too dumb to check for SSL, good luck getting them to discern insecure, 'insecure but can't be eavesdropped', and secure. Hell, most users would be shocked to find out you can eavesdrop on their traffic in the first place.
Re:Firefox isn't helping (Score:5, Insightful)
Most users are too dumb to check for SSL, good luck getting them to discern insecure, 'insecure but can't be eavesdropped', and secure.
Fair enough. So don't put the secure green lock up for self signed SSL. Put up a totally different icon in some neutral color like blue. If they click on it it says, the connection is encrypted and can't be eavesdropped but there is no gaurantee you are talking to who you think you are.
Hell, most users would be shocked to find out you can eavesdrop on their traffic in the first place.
Good point! Maybe firefox 3 should pop up a huge error screen every time you try to connect to a site with plain http. It could say something like:
The server you are connecting to is insecure. Maybe there is a configuration error on the server. Or maybe someone is trying to impersonate it. Oh, and by the way, not only that, but any communication with them maybe trivially intercepted by any 3rd party...
Are you sure you want to communicate with them?
Then it could have friendly buttons like:
"Hell no get me out of here." or "Ok, I don't mind getting pnwed!"
Re:Firefox isn't helping (Score:5, Interesting)
Re: (Score:2)
What's difficult is if I'm technically capable of eavesdropping, I'm technically capable of MitM and thus a self-signed certificate doesn't add any extra security.
It's very difficult to provide an explanation. Think about car locks, right? Car locks aren't secure; I can brick your window and steal your shit. People don't, so the (straw man) argument is that there's increased security, and self-signed SSL certs will increase security.
But if you consider the differences here you should notice that someon
Re: (Score:3, Insightful)
What's difficult is if I'm technically capable of eavesdropping, I'm technically capable of MitM and thus a self-signed certificate doesn't add any extra security.
So have the browser treat it as being unsigned. Don't do anything special. Don't put up a big green lock. Don't make a fuss. Even if its not really MORE secure, its certainly not LESS secure, so firefox at WORST should treat it exactly the same as plain http.
Re:Firefox isn't helping (Score:5, Insightful)
I dunno. I just click "Okay" until the windows go away and I can see the website.
Re: (Score:3, Insightful)
Re: (Score:2)
In that case don't display a damned lock when there is an unsigned certificate. Really how much of an idiot do you have to be to not be able to see that simple solution?
And yes, it really is true idiocy to treat an unsigned certificate transmission worse than a plain text transmission. Point Haired Boss worthy material.
Re: (Score:2)
Re: (Score:2)
Parent is Trolling. (Score:3, Informative)
Self signed certs can not be authenticated...
I really wish you people would stop whining...
Signed,
Someone with an actual clue about cryptography.
Oh?
You are so clueful about crypto that you don't know what fingerprints and out-of-band authentication are?
My.
Self-signed SSL certs work marvelously in a number of use cases:
A) When an admin or user adds the cert to a client machine (like a laptop) in a secure environment.
B) When fingerprints are verified out of band, such as over the phone, over alternate sites and protocols, printed correspondence, etc...
C) When its only necessary to know that you are communicating with the same party you were last time.
Re: (Score:3, Insightful)
It should by default accept a self-signed cert transparently without any fuss. It SHOULDN'T show a big green lock. It should just be a regular connection. If the self-signed cert changes on a subsequent visit, THEN they should get a warning. That's it.
The problem is, we've tried to train users to look for the "https" or the lock, or both. Getting rid of the lock for self-signed connections is fine, but the https is still there, and it's misleading.
OE is a nice idea (Score:2)
Opportunistic encryption was the original goal of the FreeS/WAN [freeswan.org] project. It was not realised, and the eventual forks (OpenSwan and strongSwan) are now aimed more at running IPSEC tunnels.
Re:OE is a nice idea (Score:4, Informative)
That depends on your definition of "not realized". Before the FreeS/WAN project was abandoned, opportunistic encryption had been implemented and was in use. Adoption was probably quite small, but it existed.
surveillance (Score:5, Insightful)
The video starts out saying that increased encryption is needed thanks in part to warrantless government surveillance. It then goes on to describe a system that assumes no MITM attacks can exist. The fact is, however, that governments are entirely capable of performing MITM attacks, as can telecommunications companies; and if it becomes popular we may see more techniques that allow individuals to perform MITM attacks. While this algorithm has significant merit, care needs to be taken to avoid a false sense of security.
Re: (Score:3, Insightful)
Which is why the video states that SSL/TLS should be the only user visible transport security and their third goal is to have no visual indications and no alternative URL schemes.
Re:surveillance (Score:5, Insightful)
It does not "assume no MITM attacks can exist". It deliberately does not protect against them. This is not the same thing, as one is a position of ignorance whereas the other is an intentional choice not to defend against that threat.
In practical terms, MITM is considerably harder than simply listening in. Wide-scale surveillance such as what caused the big recent flap with FISA and the NSA simply can't perform MITM attacks. Protecting against pure eavesdropping while remaining open to MITM attacks is useful, it's just not a 100% solution. As long as it doesn't sell itself as one (and I see no indication that it is) then there's absolutely no problem with that.
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
That's not really the point though. It raises the bar of work needed to implement these snooping systems and can prevent ISPs from placing their own adverts into webpages.
Re: (Score:3, Insightful)
can prevent ISPs from placing their own adverts into webpages.
Exactly - this is what Google is interested in. If ISPs start replacing Google adverts in web pages with their own (or worse, the AdWords adverts in Google search results), then Google will lose huge amounts of revenue. Luckily, but only by chance, Google's self-interest in this case is aligned with ours.
Rich.
Re: (Score:3, Informative)
The person who wrote Obfuscated TCP works for Google.
Rich.
NOT GOOGLE (Score:5, Informative)
This is not GOOGLE's Obfuscated TCP, this is a small one-man project HOSTED on Google Code.
That guy's gonna get tons of traffic for what's maybe a good idea but not endorsed or supported by Google.
Re:NOT GOOGLE (Score:5, Informative)
He's a Google employee. [blogspot.com].
(Standard 20% time disclaimer etc)
Re: (Score:2, Informative)
Official Google projects use the "Google" label, including 20% projects: http://code.google.com/hosting/search?q=label%3AGoogle [google.com]
So either this wasn't a work-related process, or he forgot.
Less secure than 128bit SSL? Why? (Score:4, Insightful)
By providing a less secure, but computationally and administratively cheaper, method of encryption, we might be able to increase the depressingly small fraction of encrypted traffic on the Internet.
If the encryption is computationally cheaper, then the decryption is computationally cheaper. I'd rather people know that what they're sending over the 'net can be sniffed than have them think that because example.com uses Rot13 encryption their traffic is private.
Re: (Score:2, Informative)
If the encryption is computationally cheaper, then the decryption is computationally cheaper. I'd rather people know that what they're sending over the 'net can be sniffed than have them think that because example.com uses Rot13 encryption their traffic is private.
A few key points:
Trusts DNS instead of CA signature (Score:5, Insightful)
So, basically we have the same concept as SSL, except instead of trusting the CA signature on the certificate, we trust DNS.
Forging a CA signature on a certificate would be a BIG DEAL.
Forging a DNS entry, especially with ISP cooperation(read government snooping), is DEAD SIMPLE.
So we replace real security with, well, a CPU hog that's only a smidge better than running everything in the clear. It only keeps out the MOST casual, lazy, and uninterested snooper.
Re: (Score:3, Insightful)
Forging a CA signature on a certificate would be a BIG DEAL.
Forging a DNS entry, especially with ISP cooperation(read government snooping), is DEAD SIMPLE.
True, if it required you to forge a real CA's signature. The whole point of self-signed certs is that there is no CA - you're not impersonating being anyone other than the website and it has zero effect on anything else. I can make such a certificate up in a terminal in the time it takes me to type it. I don't know if it would be a bigger deal legally, but technically it is equally dead simple. And if it was legally a big deal I'm sure they can get some retroactive immunity for it.
Re: (Score:2)
Also you need either A) a CNAME (rejig your whole site) or B) hacked DNS resolver (HA! I bet only an eighth of ISP DNS server even handle more than the common records correctly as is).
Basically what is outlined is if you own example.com, you make a web site http://www.example.com/ [example.com] and then have:
www.example.com. 30 IN CNAME 0000000abcdef.abcdef.example.com.
0000000abcdef.abcdef.example.com. 30 IN A 1.2.3.4
The hex is a key and a tcp port. It would be trivial as you said for the ISP to deliver instead:
www.examp
They could have done better (Score:5, Interesting)
I read the technical details [google.com] and they talk about an advert being encoded in the CNAME, to distribute a curve25519 key and a port number. But they could have done much simpler using technology that already exists: encode the 160-bit SHA1 fingerprint of an X.509 certificate and a port number in the CNAME (only 32 chars needed in base32). Then connect to this port using HTTPS and simply verify that the certificate matches the fingerprint ! Advantages:
Re:They could have done better (Score:4, Insightful)
Re: (Score:3, Informative)
One of the main points of this is that it's faster, however you didn't mention any comparison.
Re: (Score:2)
Re: (Score:2)
Imple-say! (Score:2)
what's wrong with ipsec? (Score:4, Interesting)
Seriously, not trying to troll, but wasn't this problem solved more completely by IPSEC back in 2000? Why hasn't IPSEC been adopted more? Why should this solution fare any better?
Re:what's wrong with ipsec? (Score:5, Informative)
IPSec prevents its own widespread adoption in two ways:
1) IPSec is very much about authenticating who you are talking to on the other end. If two nodes connect for the first time, with no previous knowledge, they have no way to authenticate the other is who they say they are. This is a failure to IPSec - you'll get no SAs, and most implementations will drop traffic that would've required that SA.
2) The classic key exchange issue:
a) You can authenticate a session using certs, but now you have the same problems as signed SSL certs, except that every host participating needs to have one and know about all the other nodes' CAs.
b) You can instead opt to use a pre-shared key, but now you have to pre-share the key. This is fine when you are looking to secure specific traffic to a specific node.
For uses that aren't affected by these downsides, IPSec is a hugely popular technology. VPNs between a branch and central office as well as remote access for roaming users are very popular. Of course in these cases you can very meaningfully authenticate the other end and the key exchange isn't a problem.
Re:what's wrong with ipsec? (Score:5, Funny)
Ever set up IPSEC? Yeah, that's why.
Any commonplace encryption is helpful (Score:4, Insightful)
we might be able to increase the depressingly small fraction of encrypted traffic on the Internet.
I agree that this would indeed be a good thing for several reasons. An encrypted message in a medium where most everything is plaintext may attract the attention of attackers or, worse, be seen as "suspicious" by a government. (Certainly the U.S. and the PATRIOT Act spring to mind, but let's not forget the truly oppressive governments such as China's and any number of third-world dictatorships.) If online privacy via encryption comes to be a right that everyone gets used to enjoying—much like how almost all mail is sent in sealed envelopes, whether or not its contents are sensitive—then it will be that much harder, for technical and/or social reasons, for an authority to take away. If Obfuscated TCP is even a token step in that direction (and it seems to be a bit better than that), then it is probably a good thing overall.
Someone earlier today on Slashdot was plugging Cory Doctorow's Little Brother, and I'm going to follow that example (you can read it for free!) [craphound.com] as part of it advances the same idea.
Reinventing ancient history (Score:5, Informative)
It's interesting how the same idea gets "reinvented" over and over. Opportunistic encryption using advertised DH public numbers is just such a thing.
ObsTCP is just a reinvention of SKIP.
See here via the Wayback Machine since the concept is long dead and buried.
http://web.archive.org/web/20021129230049/http://www.skip-vpn.org/ [archive.org]
Weak encryption worse than none. (Score:4, Insightful)
"By providing a less secure, but computationally and administratively cheaper, method of encryption, we might be able to..." give people a false sense of security.
Remember, weak encryption can be worse than none as Mary Queen of Scots found out at the cost of her life (see http://www.nikon.com/about/feelnikon/light/chap04/sec01.htm [nikon.com]).
Equivalent to SSH/TLS with self-signed certs. (Score:2)
This is equivalent, in a security sense, to SSH/TLS with self-signed certs. There's no protection against man-in-the-middle attacks, but there is some protection against passive eavesdroppers.
Unfortunately, man-in-the-middle attacks are most likely in the same situation that allows easy passive eavesdropping - public WiFi access points.
Also, they've chosen completely different cryptographic standards than SSH/TLS uses, with different key handling. Until many qualified people have gone over exactly ho
vote for kdawson to be fired (Score:2)
kdawson, you are a king(queen?) among idiots. And the submitter, agl42, is a bastard prince(ss).
how did it escape both of you that google code != Google?
Why not use mod-gzip? (Score:3, Interesting)
If the objective is to prevent large-scale keyword sniffing, then you can obfuscate it with compression.
The support is already built into the browsers.
Yes I know its not encryption, but if everything was gzip'd then it would cost the listener more to decrypt it. Plus gzip'd data would not invite any added attention.
Just make it cheaper (Score:3, Insightful)
Just make SSL cert cheaper and get rid of all the multiple server licensing and crap.
Make the damn thing ran by a non-profit organization and cut the cost.
Re:The implications? (Score:5, Interesting)
Why?
If you watch the "video", one of their explicit points (#2) is that the user shouldn't be informed of this. This will not trigger the little security lock icon. From a user's point of view, you shouldn't be able to tell if the web server you are connected to is unsecured or secured this this little bit of obfuscation.
This isn't for real security, it's to make simple sniffing harder. As the video puts it, it simply raises the bar for someone who wants to read other people's traffic.
It seems like a very good idea to me. It sounds quite intelligent (from what I know of TCP/IP, etc). Some protocols have need changes (protocols where there is one connection and it isn't dropped would need some way to communicate that the encryption is OK during the first (and possibly only) connection.
Either way, it sounds like quite an improvement over what we have now.
Re: (Score:2)
Yes, half of the exchange not knowing that there is "encryption" going on is definitely a plus.
That point alone seems to me a good reason to be suspicious.
Arrgghh! No more videos! (Score:5, Insightful)
If you watch the video, your brain will leak out through your ears. It's terrible. Why produce a video which seems to be a black screen with a dark blue line wiggling when the person talks? Why pick a person with a crappy British accent and a speech impediment? Who's going to understand? Why flash up a couple of words here and there like "SSL" and "HTTP"? Why produce such a steaming pile of crap and call it an "introductory video"?
Instead, whoever is the video star in this could have written down their ideas in plain text. That would allow for easy reading and comprehension by people all over the world. Maybe I can read quickly. Maybe I don't want to sit around waiting for you to lisp and stammer through your presentation. Maybe I'd understand it better if I read it than if I heard it on a crappy video. Maybe I don't want to waste my bandwidth downloading several megabytes of video, where the same information in plain text might be a few kilobytes.
Re:Arrgghh! No more videos! (Score:4, Insightful)
I'm glad I'm not the only one who feels this way. It takes way more time to absorb information from a video - more than I'm usually willing to give.
If you must make a video, at least provide a transcript.
Re: (Score:3, Insightful)
Maybe that's the whole reason it was put on video instead. For some ideas, understanding it and thinking it is a good idea are inversely related. This sounds line one of those.
Re: (Score:2, Insightful)
Re:The implications? (Score:5, Funny)
This. Is. SLASHDOT!
Re:The implications? (Score:5, Insightful)
It may be slightly off-topic but the parent has a VERY valid point. Self-signed sites are encrypted but best of luck trying to get people to use them thanks to the 3-clicks required and SMALL text. When I used the new firefox release I was even confused at first.
Now back to obfuscated TCP: This is on par with using NAT to fix the lack of IP addresses. Just fix the damn thing properly and stop screwing around with time wasting half-fixes (yeah they admitted it).
About the only thing this is going to do is make troubleshooting problems with Ethereal or other packet sniffers a pain in the a$$. Thanks.
Net neutrality. user owned. (Score:3, Interesting)
No, This is about making the net more neutral.
ISP cannot look into obfuscated traffic, and thus cannot traffic shape it. (note that torrent/eMule is also obfuscated enabled)
ISP/NSA cannot datamine obfuscated traffic. Only targetted traffic can be obfuscated.
State censors cannot block traffic based on keywords. (chinese wall)
It is more a "why not?" statement.
Re: (Score:3, Insightful)
You answered your own "why not?"
NSA and ISPs like to snoop, data mine and traffic shape. Traffic shaping can even be a good thing in certain situations (and I'm not talking Comcast here.) It's highly unlikely anything like obstcp will ever get standardized, since it prevents exactly what you just mentioned.
Re:The implications? (Score:5, Interesting)
Self-certified certificates are worse than plain unencrypted traffic because of psychological reasons, not because of technical reasons.
Your ISP can easily and automatically intercept self-signed certificates and present their own certificate, which you will gladly accept. Now you think that you are less secure than a verified certificate but still "somewhat secure". Technically, you are however protected as much as plain unencrypted HTTP.
Now, this is where humans fail. Because you still think you are "somewhat safe", you will take higher risks, write things that you would normally not write, click on links that you perhaps wouldn't click on over a plain non-encrypted page. The famous false sense of security, which actually does nothing except making you feel good.
Re:The implications? (Score:5, Insightful)
you're [sic] traffic's still encrypted and secure from eavesdropping
Except from the party that did the MITM attack, which is most often the party that you want to prevent watching your traffic, you know, the one that is actually interested in sniffing your traffic..
Re:The implications? (Score:5, Interesting)
Um, no. It's so that it costs more to index the web, meaning that any competitor to google has to pay more to challenge their dominant position as search engine. Microsoft has to bleed even more money trying to compete. Yahoo might have to abandon search.
TFA explains how Obfuscated TCP is both opportunistic and transparent. Servers will provide encrypted transmission only when the client requests it, and unlike SSL/TLS there is no additional handshaking required to setup the connection.
A car analogy. Suppose you use regular unleaded fuel in your car and it drives fine. High octane fuel then becomes available at a higher cost. Your car continues to drive fine on regular unleaded, but you have the choice to fill up with high octane at any petrol station that serves it.
This costs you more, how?
Re:The implications? (Score:5, Insightful)
Re: (Score:3, Insightful)
He signs posts:
Adam Langley
Google Engineering
... not google's idea?
Re:The implications? (Score:5, Insightful)
Implications?
but it can assuage untargeted, dragnet sniffing of backbones
Can you read the subtext there? Snap, how's that for an implication? Privacy. (from the government.)
Re:So, wait... (Score:5, Informative)
It's not written by Google, it's just hosted by them. Big difference, misleading title.
Re: (Score:3, Insightful)
>
Are we supposed to like Google or not now?
I'm confused :(
Realizing that large corporations consist of many separate interests might help alleviate your confusion :-)
Project owner's page is at: http://www.imperialviolet.org/ [imperialviolet.org] if you wanted more info.
Re: (Score:2)
Re: (Score:2)
I agree. What is wrong with self signed certs? Scary warnings from the browser? That can be educated. Too slow? Hardware is faster now.
Re: (Score:2)
That is why you check the cert and add it to your personal list of allowed (by checking it carefully you prevented the initial MITM). Then if the cert ever changes you get notified of the change (catching a later MITM). Again like I said, I am not against the scary warnings, I'm for user education. It is simply a user education thing.
Re: (Score:2)
I had hosting at provider that did this:
them: http://example.com/ [example.com]
me: http://foo.bar.invalid/ [foo.bar.invalid]
them: https://example.com/ [example.com]
me: https://example.com/bar/foo/ [example.com]
They paid for the example.com cert.
Re: (Score:2)
That's actually a problem with OpenSSL and mod_ssl. Check out mod_gnutls and gnutls for an approach where name-based virtual hosts can each have their own certificate that validates in most current browsers (Safari, Opera, Firefox, IE7).
Re: (Score:3, Interesting)
This is SNI ( http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org] ) and it is not supported on Safari (any version I am aware of I just tried a nightly build on an intel iMac) nor on any version of IE on XP or earlier. You can verify by visiting https://sni.velox.ch/ [velox.ch] and see if you get a warning.
Also you don't need gnutls for SNI since support for SNI has been backported into OpenSSL 0.9.8: http://cvs.openssl.org/chngview?cn=16435 [openssl.org]
Re: (Score:2)
Re:Problem isn't computation... (Score:5, Informative)
I would disagree. One of the biggest barriers to implementing SSL on my sites is the lack of IP addresses. I only have two IP addresses, yet I host 16 web sites. My understanding is that HTTPS requires IP based virtuals which would prevent me from hosting more than two sites if I were to use SSL for all of my sites.
Re:Problem isn't computation... (Score:5, Informative)
My understanding is that HTTPS requires IP based virtuals
Partly. There's a TLS extension [wikipedia.org] that makes it work, but it looks like it doesn't work for IE on WinXP.
Re:Problem isn't computation... (Score:5, Insightful)
Anybody remembers what hapenned to RFC 2817 [ietf.org] ? It tried to address this very pb by introducing the "Upgrade: TLS/1.0" header and the "426 Upgrade Required" status code, but I don't think any browser or server implement them.
Re: (Score:3, Interesting)
Except there's a bug in IE where you cannot change the protocol (http->https) and the port at the same time. Maybe they've wised up and fixed it; I don't use IE whenever possible.
Re:Problem isn't computation... (Score:5, Insightful)
Running your web sites on non-standard ports is a great way for your web site not to be accessible to users accessing the internet through firewalls that limit egress traffic based on TCP destination ports.
Re:Problem isn't computation... (Score:5, Insightful)
For a public site using non-standard ports is an easy method to shoot yourself in the foot - you immediately block all users behind proxies or firewalls that only allow communication on "standard" web ports.
Re: (Score:2)
Or you could have the forms and what not use https://example.com/foo/action [example.com] and https://example.com/bar/action [example.com] for your different sites. There is the possibility of a MITM creating a copy of your site with the action pointing to http://evil.invalid/foo/action [evil.invalid] instead though but maybe these sites are not so important. Alternatively you could simply let everyone know that the site is really at https://example.com/foo/ [example.com] and the other is at https://example.com/bar/ [example.com].
Re: (Score:2)
I would say if your barrier to SSL is lack of IPs you should probably find a provider who isn't running out of their moms basement and has a few they can give you.
Re: (Score:2)
Those are some expensive ten lines of perl code then.
Re: (Score:2)
I'm assuming you also don't want your ISP inserting adverts into your slashdot?
You might not mind but I do mind, encrypting all traffic means no advert inserting, no network neutrality problems, no US government reading my email, etc.
Yeah, they might break the encryption, but so what? Just plug the security hole and continue.