Comment by kristofferR | Hacker News Reader

Comment by kristofferR | Hacker News Reader

Forced SSL is not a problem for big sites like FB and medium size sites, but it is incredibly problematic for the small sites with less than a couple of thousand visitors per month, in effect it means that SPDY (and eventually HTTP 2.0 unfortunately) will remain a bonus for the elite web sites while the majority of the smaller web sites will remain on HTTP 1.1 "forever".

Yeah, I'm aware that some providers like StartSSL hands out free SSL certificates, but I don't think it's a good sign of things to come that you need to hand over sensitive personal information in order to use the latest generation of a fundemental web technology. You'll also need a dedicated IP, which costs money and is becoming increasingly scarce and expensive.

I actually run a small web host for my clients and all of them have denied my offer to install a free SSL from StartSSL in order to get SPDY because of the privacy concerns and the extra cost of the dedicated IP they're required to get.

It's a shame that a large majority of the web sites on the net will become stuck on an old technology just because of an arbitrary requirement for encryption even though they have nothing to secure anyway.

I'd hope that anyone speaking SPDY would also be SNI-capable, thus negating the usual need for one IP+port per certificate.

Granted, it does nothing for your older non-SNI browsers, but they won't be speaking SPDY or HTTP/2.0 or whatever it winds up being called.

http://en.wikipedia.org/wiki/Server_Name_Indication

Yes you are so correct.

SPDY is for the future.

Getting a SSL certificate is not a big issue and not too costly. And for blogs and simple websites SPDY adds less. So don't implemmnt it.

So why anyone needs to worry?

On spdy-dev they considered adding SNI to the spec as a requirement but didn't:

https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/...

(At this point implementing SPDY without SNI would be kind of absurd, but it would be spec-conforming.)

Android browser supports SPDY but doesn't support SNI.

Versions of Android that support SPDY also support SNI.

The problem is the conflation of security and identity. You need security to guarantee identity, but not the other way around. I see no reason that we can't have encrypted connections without identity.

Ssh has basically solved this. If you're like 99% of ssh users, you just accept the key the server gave you without verification. Your browser could do the same on the web -- just accept the server certificate and then indicate to you that the connection is secure but the servers identity is not verified.

This solves pretty much all the issues you bring up.

And if http 2 required it,then even better, because all the server would support it and all the clients would too.

That solution simply does not work. If your browser will accept the certificate that the server presents, anyone can pretend to be anyone and your browser will accept it. Enforcing identity is just as important as encrypting the connection.

You can do that identity enforcement through some scheme (accept-first-time, or web-of-trust, or something else) but they all have significant downsides. It's not an easy problem.

> If your browser will accept the certificate that the server presents, anyone can pretend to be anyone and your browser will accept it.

Yes but at least the data is protected from eavesdroppers that don't control any hardware in the line of the connection, which is better than nothing.

Most browsers let you accept a particular certificate for a particular site already, just like SSH, so you can already have this if you want. Part of the reason it works so well for SSH, though, is "security through unpopularity": you don't have large numbers of naïve users doing online banking at Starbucks over SSH. If SSH became more popular, you'd need to verify the fingerprint, and then you're back to square one ("If I have a secure channel with which to verify the identity of the SSH key, why not just use this same channel to establish the secure session?").

Except that if I want to accept a self signed certificate I have to click 6 times through scary warning screens.

And that is a good thing because that cert is for both encryption and identity.

If it were JUST for encryption, there'd be no issue just auto accepting that certificate.

I hope that deployment of SPDY with smaller sites (and the problems that appear with that) might help kill the CA extortion scheme in favor of something decentralized (convergence.io is one experiment in that direction).

Every mass hoster (incl. those $9/mo PHP hosts) is affected eventually...

You already have to provide such personal information to register a domain, it's not a new development.

SNI or a dedicated IP is not required if you use a single certificate with multiple domain names.

Also you don't really hand over more sensitive personal details than you already provide to most web hosting companies. The only additional requirement was a copy of my personal id.

Finally, Chrome does support self-signed certificates authenticated using DNSSEC and there is work going on to make that a standard (DANE).

Preventing intermediate routers from screwing with the protocol is a higher priority. Microsoft already has an embrace-extend-extinguish proposal aimed at mobile networks, and that could easily make the protocol unusable. The websocket handshake required a ridiculous number of iterations to not trigger bugs in middleboxes. As a nice side effect, encryption everywhere removes some of the payoff for traffic interception by ISPs, like BT's attempted deployment of Phorm adware.

Yea, Microsoft Speed+Mobility don't have the SSL requirement, because it is based on WebSockets which already have done the work (masking etc.) to deal with bad middleboxes. And SPDY and WebSockets was developed at the same company (Google), yet it is MS that realized both can be combined together.

In fact, looks like WebSockets was developed by Ian Hickson at Google, while SPDY was developed by Mike Belshe at Google: http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...

IP issues will go away when IPv6 catches on and things like this will only increase adoption.

What is the IP issue with SPDY?

Serving multiple SSL websites on different domains on the same IP address requires the SNI extension and much fiddling around; it is ill-supported by old browsers. This is needed because with HTTPS, the header that tells the server which site to serve is still encrypted when the server needs to direct the request to the relevant application code. IPv6 will fix this by allowing you to easily give each application on your server its own IP as well as its own domain. This is simply because IPv6 creates a lot more addresses so we won't have to ration them like we do now.

Sorry, that's a poorly worded explanation, but its sunday morning. Have a look at https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_I...

That's irrelevant to parent's question, since old browsers won't support SPDY at all.

Even so, SPDY support does not imply SNI support.

SPDY uses SSL and as it stands anything that doesn't support SNI will only accept one SSL certificate on one IP address. So if you run n certs on the same box you'd need n IP addresses.

There is no issue with IP addresses and SPDY perse. It's just that for SSL encryption (HTTPS) to work currently you would need your own IP address as older browsers (read IE < 8 on windows XP) don't support the SNI method of setting up HTTPS where you don't need your own IP address.

So as I thought, no issues (I don't think IE < 8 is likely to be an issue wrt SPDY support).

Reply on news.ycombinator.com