On Nov 16, 3:11 pm, "[email protected]" <[email protected]> wrote: > On Nov 14, 12:55 am, Bram Cohen <[email protected]> wrote: > > > First and foremost: What is the transition plan? > > We need to nail this down. Here are the two leading options we like: > a) Run over SSL & modify the SSL handshake to carry additional > information about the protocol to select at the higher level. > b) Roll the HTTP version number; only after a successful HTTP/2.0 (or > whatever) versioned response does it move into SPDY mode.
I don't think (a) is a viable option. If you speaking SSL from the get- go, connections to legacy servers (which for now is all of them) will simply fail, which is unacceptable. (b) is technically speaking a viable plan, but it has major downsides and accomplishes less than what a much simpler approach could accomplish. The upside: hey, it works The downsides: It adds two(!) whole round trips - one for the the handshake, one for SSL. It leaks the initial url requested. It doesn't provide any blockage against man in the middle attacks whatsoever, because an interloper who is doing DNS hijacking can simply not use SPDY. That last problem isn't really a problem per se. There are two possible approaches you can take with SPDY - (1) have a transition plan which works smoothly with legacy systems. This has the possibility of adding some encryption, but not authentication, because an interloper can simply use the legacy protocol. It can also, of course, provide all of SPDY's core non- crypto functionality, which is a very good thing. (2) have a transition plan which requires a clear jump, and have SPDY fail. Given those options, I'd rather go with (1). In particular, even with approach (b), there's still the issue of whether to require authenticated signatures. Disallowing or providing security warnings against self-signed certs will result in the same two things it has with https: (1) making buttloads of money for verisign (2) resulting in very little deployment Neither of which are particularly appealing. All that said, even if no cert checking is done for approach (b), I'm still against it, for purely technical reasons. If a protocol is to provide encryption without authentication, it can do so with vastly less overhead, round-trips, and overall baggage than SSL. For example, here's an approach: the server puts an ECC-based public key in its DNS information, the client then sees this and starts its http connection with a diffie-hellman key exchange, and thereafter both sides encrypt everything in counter mode. Presto, you're done. No extra round trips, only very simple, easy to understand crypto. Only a few dozen extra bytes of bandwidth overhead and very little extra CPU. This very specific approach might have its own problems, and I'm not proposing it as something for you to go ahead and implement right now, but it's definitely the case that it's possible to do a lot better than simply slapping SSL on everything. As I said before, I'm very much in favor of an encrypted web, but I think that tying together a plan for transitioning the web to having decent pipelining and a plan for making it encrypted is likely to make both of them fail. Please don't think that by having this great spdy thing you can leverage it to force people into doing cert stuff. The most likely outcome for spdy is still failure to be widely deployed. Unrelated to all of the above issues, approach (b) also gives up on existing proxies working with the new protocol, unless you hack it so that servers notice when the thing's being proxied and go legacy, which might actually be the best method. > > Terminating POST requests with an empty frame is a gross hack. Making > > it have real semantics would be nicer and more flexible. For starters, > > it could differentiate between cancelled and finished requests. > > Maybe we have a hole in the docs; but there is a FIN_FLAG which can be > carried on most of the control or any data packet. While you can send > a zero-length frame with the FIN bit, more efficient is to just put > the FIN bit on the last frame. In the SPDY protocol doc it says: The POST data stream is terminated by a zero-length data frame. > > I'm skeptical of the proposed prioritization scheme's utility. While > > there's nothing particularly wrong with including it, I suspect that > > server-based heuristics for determining what to send first are likely > > to work a lot better. The simplest such scheme is to send all html > > objects first, followed by all flash objects, then images, and finally > > video. Within each type sort by size and send the smallest objects > > first. I suspect it's hard to improve on this simple approach. > > Alright - you are just proposing mime-types instead of numbers, that > is basically what we do but numbers are easier to sort. Ah, so your client-side strategy is mostly to prioritize based on mimetype? In that case I think it's fine, but only having four priority levels might not be enough. I assumed that priority levels were mostly being used to make new tabs take priority over old tabs, which is actually a much more subtle set of issues - a user might flip back and forth between multiple tabs being in the front repeatedly, and the back end should be able to communicate those changes in priority up to the server efficiently. > When we think of protocols of the future, we think it is intolerable > that you could connect to your bank and not have the site actually be > your bank. Why our protocols allow this even today is embarrassing. > The amount of money lost annually due to failing to protect > communications is absurd. We have to solve it. While I agree with your sentiment and view it as laudable, I've seen it before and am trying to warn you off the common mistakes everyone makes, in the interests of getting both pipelining and encryption deployed as widely as possible. I have a wee bit of experience getting protocols to be widely deployed :-) > We will use this opportunity to improve SSL performance as well; and > we believe that hardware has improved enough that the scalability > issues here are minimal. The main way to improve SSL is to only use it with ECC and AES. It's a protocol with a lot of baggage and crap in it. > > There's a > > reason why http and https are separate protocols, and the one stupid > > little fact that they require different urls is the main reason why > > encryption of web traffic isn't a lot more widespread than it is > > currently. > > We could get into historical reasons why we are where we are. > > I think the primary reason is that http existed first, and it didn't > make sense to nuke all of http in favor of a costly, slow, and > unproven SSL. Since then, we've lived with two protocols. Oh if only it were that innocent. SSL was some hacked together crap from some guys at Netscape (even the crypto on SSL 1.0 was seriously busted, this was back before there were any standards to use) who had much the same hopes and goals as you do. The reason they made the http/ https distinction is that they wanted to make it as secure as possible and just plain didn't take the problem of transition seriously, and it failed even though Netscape back then had a LOT more leverage than Google does today with Chrome. I once asked someone who was involved from the Netscape side why it was that Netscape handed over the cert business to Verisign, and his answer was simply 'We got played.' The reason that I'm being such a jerk about what the transition plan is is that even though it seems like an annoying technical detail it's in fact absolutely central to the protocol, and it's very difficult to get right. > How many user studies showing that users don't notice the padlock > indicating SSL do we need to read before we realize that users > shouldn't need to make a conscious choice for security? I agree, although by that measure browsers today are downright bad actors, providing dire security warnings for web sites whose certs are borked, even for something as innocent as having the cert be for www.x.com when you're at x.com, while never giving any security warnings whatsoever for plaintext. -Bram -- Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss
