Brad Ideas - security - Comments

StartCom now support

Robert — Sun, 27 Sep 2009 14:05:00 -0700

Good news: StartCom is now supported by Microsoft! Microsoft just included StartCom's root certificate in their trusted store so it will be supported without warnings on all newer Microsoft products: http://www.sslshopper.com/article-microsoft-adds-support-for-startcom-ce...

As a user I need just

Anonymous — Wed, 16 Sep 2009 23:08:15 -0700

As a user I need just encryption, no authentication. I don't care whether another site impersonates the service I want to use, but I care about encrypting the traffic. TLS and SSL would be a lot simpler if we could use them without certificates at all. We can have encryption without authentication and in 99% of cases that's what we users need.

The implementation is the tech

brad — Sun, 23 Aug 2009 10:30:48 -0700

And the quality of the implementation is what affects the deployment. It is pointless to design a wonderful system that does not get deployed because it is not properly designed for the qualities users are looking for. Users want security, but most of them demand convenience, ease of use and ease of learning or they will never install it.

I don’t agree, I don’t think it’s a matter of cost at all — other than with more money you would hire protocol designers who know how to build tools users will actually deploy.

You are right but...

Anonymous — Sun, 23 Aug 2009 02:02:18 -0700

You are right, the tools suck. But the protocols themselves (certs, ssl, etc.) are 1) are pretty damn efficient for what they do and 2) pretty solid. Don't point fingers at the tech, but rather the implementation.

Elliptic curve cryptography is not well developed, that's why it's not a good alternative. A better alternative to the round trip problem might be to use session caching with user configured/directed re-keying appropriate for use. No matter what though, such gains in efficiency must be implemented first on servers - which have the economic problem of low distribution numbers and therefore short budgets.

This is the real problem that needs to be solved: developing secure software is expensive, time consuming, and increases your liability as a software provider. Even just researching crpto technologies can be a liability. Find a way to reduce secure software development costs, and you'll find yourself inundated with excellent tools and protocols...

costs of handshake

Anonymous — Thu, 16 Jul 2009 02:47:27 -0700

I like that you considered costs of the handshake and Moore's Law. That is wise thinking. I only wish I saw this point being made in the context of video streaming. There's Adobe's (Macromedia's) campaign with rtsp. That's a fairly simple handshake that has been documented. I'd guess many are aware of it. But have you looked at Ooyala? It's even more annoying. All in the interests of "analytics" ($$). There is actually a POST made after the user issues a GET, unbeknownst to the user, unless he watches the HTTP transaction.

Latency

brad — Tue, 07 Jul 2009 11:17:20 -0700

Yes Bram, I write about the latency as the big issue in the original article.

DNS does not come from something close by, unless it’s cached. The DNS server for 4brad.com is in fact the same as the web server, and this is quite common. If it’s your first hit (or the first hit by your cache) on the domain, then packets come all the way here and back, which is why it would be super efficient for the DNS server to be able to just forward or even answer the query.

In theory, a DNS request could involve first asking the root (who is fairly local) where “com” is — but effectively that’s almost always in the cache. You must then ask com where 4brad.com is — that also is likely to be one of the nearby mirrors, but won’t be in the cache if it’s your first hit on the site since the TTL expired. Finally you must ask 4brad.com’s DNS server where ideas.4brad.com is (on most sites it is www.foo.com you will be asking about) which is a round trip all the way to the target.

For big sites like www.google.com it’s almost surely in the shared cache. For small sites it quite often isn’t. When sites have set a very short TTL in order to do round robin DNS, you are doing this dance much more frequently.

Now it turns out that today’s web transaction usually consists of fetching a page and a bunch of embedded images, css and scripts on the first hit, and this is almost always done in a single keep-alive session. Because of this, the burdens of a TCP socket (or even a TLS channel) are relatively much smaller. The “simple web transaction” where you send out a GET and get back a modest sized HTML page almost never happens on the first hit, though it is frequent on later hits and particularly on ajax hits.

Later hits, of course, can use encryption keys negotiated on the first hit if you do it right.

The issue with multiple

Bram Cohen — Tue, 07 Jul 2009 07:41:45 -0700

The issue with multiple round trips isn't so much the fact of the round trips as it is the latency introduced, which is created by speed of light issues. Since the initial DNS lookup comes from something very close by geographically, it doesn't really add much to latency. The bigger problem is the second round trip needed for the syn cookie. Dropping that would improve real world latency quite a bit, although I'm not sure what a good way to do that is. There's also the general suckage of TCP-based congestion control, which at the moment is partially a product of the gamma being low for broadband, but the bigger problem is that it's based on dropped packets instead of increased one way delays, so it always fills up the queue, hitting the problem that routers have queues which are way too big, so latency goes through the roof when TCP is transmitting at capacity.

DNS and security

brad — Tue, 30 Jun 2009 17:07:09 -0700

Indeed, though we have also suffered from poor deployment of secured DNS, and DNS has all these vulnerabilities, such as cache poisoning, so you need to secure it first.

There is also, for the most efficient possible system, a desire to not even do a DNS fetch. While today most web sessions are long (full of images) I once described the ideal form of a web fetch transaction, which would not even use TCP.

If you did not know the IP of the web server, you would not do a DNS lookup on it, wait for the response, and then send the request to the server. Instead, you would send your web fetch request to the DNS server via UDP (just as you send your DNS request to it.) It would look up the address, but instead of just responding to you with it, it would instead forward your web request directly to the web server (again by UDP) and an ACK to the DNS server. The web server would then send the answer directly to you, including its DNS information, again via UDP, and you would send an ACK to it. From then on you would have the DNS information for direct communication the next time.

As you can see this is vastly more efficient than today’s fetch, which involves DNS fetch, DNS response, SYN, SYN/ACK, ACK, HTTP Get, HTTP response packets (with ACK) and FIN. Lots and lots of round trips.

Of course, if you use this method you are letting the DNS server see your request URL on your first request, but not further ones. However, if you know a key, or can use an identity based key, you can hide your request from the DNS server. The web server would use a key provided in your request to encrypt the response to you. You might know a key, but not the DNS value because DNS values expire quickly, especially when sites are doing round robin. In the case of this, the final DNS server is generally located with the web server, so it is easy for it to forward on your request.

Putting keys and security

Bram Cohen — Tue, 30 Jun 2009 16:52:58 -0700

Putting keys and security policies into DNS would be a good way to go. The CA system we have now just makes people not use encryption.

First request

brad — Tue, 30 Jun 2009 12:38:30 -0700

Actually, it’s pretty easy to not be so vulnerable to MITM in a transparent way if you have a free, automated CA, or another authenticated channel such as secure DNS. In this case you might still be MITM’d but only by somebody who has broken the automated CA or other system.

Secured DNS makes the most sense, since our current approach always involves doing DNS first on a site before connecting to it. (Those who want to connect via raw IP could not use this.) The DNS record should be signed, and contain the public key of the web site, allowing you to open up an encrypted connection with your very first packet encrypted, and in fact with no need for round trips.

An alternate method is identity based encryption. In this case, you encrypt your first packet using the identity based key derived from the domain name. They include their certified public key in the response, and the rest of the response is encrypted using that. The identity certifying company could look at this initial packet, and spooks could look at it if they know the key of the identity CA, but they could not look at the response, nor MITM you.

The main issue with identity certs is that there is a strong incentive for the spooks to want to get the key of the identity CA, especially if more than initial requests are encrypted with it. You can make this a bit harder in a few ways. For example, one might make a formula so that the inner portion of the domain is the name of the identity CA. So instead of www.foo.com you have idcaname.foo.com as the domain of the web site, and the tools know to use that identity CA. That way there can be so many it’s hard for spooks to track them, and you can choose one you think is secure, and you can choose one in another country not under legal authority of the spooks you are afraid of. You need to figure a good way to regularly update and publish the public keys of all the identity CAs though.

malfeatures

Bram Cohen — Mon, 29 Jun 2009 21:15:17 -0700

The no referer thing is an outright malfeature, that should be handled at the html layer (is there even a way to completely ban referers at the html layer? I haven't heard of one.) Lack of transparency, both in requiring https be a separate port from http and giving security warnings if there's no signature on the certificate (even though there's no warnings for plaintext) have also been massive issues from day 1, although the crypto community hasn't exactly helped (one of my first posts to perry's list was complaining about requiring separate ports, and he mailed me back and said I was wrong and asked if I still wanted to post it, presumably to save me embarassment or something).

The multiple round tripping is also a major issue not so much because of bandwidth but because of latency - latency times aren't going down, because they're based on the speed of light, and multiple round trips are noticeable by humans.

One thing which would be very welcome would be an extension to http which did opportunistic encryption with minimal overhead both in terms of round trips and computational overhead. It would even be fine if it didn't encrypt the first request, since that's rarely sensitive and there are simple hacks to force a reload if it is anyway. MITM explicitly should not be part of the threat model, because that just results in the protocol not getting used.

StartSSL is a good start

brad — Fri, 26 Jun 2009 20:45:55 -0700

But of course it is not trusted by MSIE or Outlook. And the sad truth is, nobody wants to have to have all the IE users get a warning dialog, even if you can tell them how to install the cert and not get it in future. Worse, nobody is going to use an HTTPS URL to point to you if they know that IE users will barf. You could write a detector so the web page looks at the user-agent and offers HTTPS URLs to non-IE users and HTTP to IE users, but that’s quite a kludge.

I am glad to see BTNS, as I have said from the start that ipsec was doomed to small deployment as long as it involved a lot of work to set up keys.

But layer-religion aside, I think there are (at least) two types of reliable (ie. not just best efforts) connections we want to have on the net. Sessions and transactions. The web is a mix of those, but starts off as transactions. You don’t have to make yourself vulnerable to MITM to fix this either, if we can make a way that the web server can generate a cert for itself when it installs. (However, the CA that offers these certs is of course a tempting target.)

A lot of this would be better if we had secure DNS, something we’ve been mighty slow to deploy too. Skype provides a remarkable example. They deployed a secure system and millions were using it within months. It is not subject to MITM, but is subject to corruption of Skype, as the Chinese incident showed. But frankly I would rather have that, than nothing, which is part of the BTNS philosophy.

Free SSL and BTNS

Wes Felter — Fri, 26 Jun 2009 15:46:47 -0700

Free "domain validated" SSL certs are already available. http://www.startssl.com/ It would be cool if they had an API so that a Web server could grab a cert automatically during installation. (A phisher's paradise to be sure, but they can already write scripts to automate the signup process anyway.)

Have you done any reading about BTNS? It appears to be the IETF's "official", non-layer-violating solution. I wonder if it can be used in a ObsTCP-like way that adds no round trips. An apparent problem with both ObsTCP and BTNS is that they have to be implemented in the network stack (i.e. Windows Eight) rather than in userspace (i.e. Firefox 4.0).