|
HowIsThisDifferentFromX
Differences between ObsTCP and a variety of similar protocols
How Is ObsTCP Different From X?SSL/TLS (i.e. HTTPS)SSL/TLS is the most common protocol for establishing a secure connection on the internet today. It's used to secure web transactions under the name of https`. SSL cannot be downgraded by an attackerWhen you start a HTTPS connection, you are requiring that the server at the other end be able to speak HTTPS back to you. An attacker cannot convince both sides that the other doesn't support encryption, like they can do with ObsTCP. ObsTCP cannot require this because that would mean that every computer on the Internet would need to be upgraded at the same time. This makes SSL significantly stronger and it's capable of protecting a single connection against a powerful attacker. (technically, some versions of SSL were open to a downgrade attack, but that's been fixed) SSL can verify the identity of the computers involvedWhen you go to https://www.bankofamerica.com, the computer at the other end must present proof that it is a legitimate server for Bank of America. It can do this because several organisations exist to vet such sites (for a fee). ObsTCP doesn't do this because it would be a fatal overhead for every computer to be vetted. This means that an attacker could impersonate another computer. Programs which are using the ObsTCP connection have the information need to verify this, if they have the means to do so. (There are possible solutions to this using SSH like imprinting and identity based signatures, but given the possibility of a downgrade attack it doesn't appear to be worth the effort) SSL requires changes to programs, and that the server supports itObsTCP operates below the level of an individual program and doesn't require changes in them. Also, ObsTCP reverts to standard TCP if the server doesn't support it while SSL will fail to work at all. SSL requires additional setup timeNew ObsTCP connections are (very nearly) as fast to setup as normal TCP connections. SSL requires several additional exchanges in order to setup a connection. This can add several hundred milliseconds to the setup time for new connections. IPv6IPv6 is the new version of the Internet Protocol. ObsTCP, although currently only written for IPv4, translates perfectly well to IPv6. IPv6 does have an encryption/signing system, however, called IPSec. IPSec also exists for IPv4 (the current, ubiquitous standard)... IPSecIPSec is a standard for encrypting network packets, much like ObsTCP. However, despite over ten years of history it has almost no active deployment on the Internet at large. It is used fairly extensively for creating secure tunnels across the Internet, for example when traveling employees wish to login to a company's network. This is a very different use and ObsTCP is inapplicable here, although the reasons are somewhat technical. IPSec adds too much latencyIn order to establish a shared key between two IPSec capable computers. This is generally done with a protocol called IKE. (The IKE protocol commonly requires mutual authentication, but I'm assuming that can be changed to be opportunistic.) The IKE setup time slows down connections. Additionally, if the other computer doesn't support IPSec, the IKE key setup request might be ignored. In that case, the request has to be timed out and the connection has to back off to non-IPSec mode. If that timeout is too aggressive, we'll be backing off when it's not needed. If it's too lax, we'll be waiting for a long time before starting a normal connection. Since most hosts won't support IPSec, this is the common case and it's just too slow. IPSec has trouble with NATsNATs are devices which are commonly used to allow multiple computers to share a single Internet connection. Home "routers" are usually NAT devices. ObsTCP is designed to work through these devices seamlessly. However the IPSec standard cannot traverse them. There are several drafts for adding NAT traversal to IPSec by wrapping IPSec packets in another protocol called UDP. This adds overhead to every packet, is aesthetically unpleasant and I don't know how widely supported this is. IPSec hasn't happened yetIPSec is old by computer standards; the first standards were published in 1995. Yet it's still very rare to find it in use outside of VPNs. It seems unlikely that pushing a dead standard is going to change anything. |
Sign in to add a comment
Hi, I just wanted to ask a question: -why not using directly TLS over TCP, which is standardized, instead of such a custom encryption method ?
Indeed, TLS over TCP doesn't have overhead as HTTPS (SSL over HTTP) and I think that there are several libraries that can perform it. Furthermore, it's not hard to use with certificates...
It's possible to do TLS over TCP for example using standard Windows crypto API between C/C++ applications, using DotNet? WCF web services with a netTcpBinding endpoint...
I hope to write up a better story about the justification of some of the points which have been presented fait accompli above.
The major reason for not using TLS over TCP is that it involves several additional round trips. This additional latency is too much, sadly. I'm currently looking for some public data which backs up the private data that I have access to that confirms this. But, take www.reddit.com for one (which is probably how you came across this). The Reddit servers are currently 75ms, round-trip, away from me. Adding two round trips (150ms) to each connection is very noticeable and, since ObsTCP should be low cost for adoption, too costly.
My understanding of TLS is that it also fails to protect against the "bogus RST" scenario presented in Introduction. I can happily use tcpkill(8) against established SSL connections passing through my router, but if ObsTCP protects against these packets then that is another advantage not present in TLS. Of course, if application layers like TLS can hook in to the ObsTCP layer then all the better.
You write that IKE requires authentication but you assume it could be done opportunistically See http://www.faqs.org/rfcs/rfc4322.html,Opportunistic Encryption using the Internet Key Exchange (IKE)
Before re-inventing the wheel, you should have a look at IPsec opportunistic Encryption (as in freeswan/openswan) and the successor to that from the IETF BTNS working group:
http://www.ietf.org/internet-drafts/draft-ietf-btns-core-07.txt http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-07.txt
- IPsec OE uses DNS records to advertise the ability to do OE. A DNS request has many advantages over trying IKE directly. You always get an answer. It traverses a different path. Answers can be cached. Answers can be validated with DNSSEC. It's tied in to the ARPA tree, so is independant of the hostname you're trying to reach. Your method of inline HTTP headers can be MITM'ed.
But let me address some comments on your comparison with IPsec.
- IPsec OE works fine through NAT. Google for "initiator-oe" or "iOE". - Replacing a "dead standard" with a new one, without understanding why it failed is just setting yourself up to repeat the mistakes. Again, look at BTNS which can do anonymous IPsec, and uses channel bindings (DNS, GSSAPI, or even "ObfTCP" if you'd wanted) to promote these connections. Though really, most connections are fine being anonymous on one end (eg google servers hardly ever need to know the client, yet the client must assure itself it is talking to google)
Other problems already fixed with IPsec, and not fixed with obfTCP as I can see:
- biddown attacks (esp when used with HTTP headers and non-secured DNS) - DoS attacks using TCP-RST'ing connections - there is more then port 80 traffic - and more then TCP traffic. - If you're securing communications with some kind of DH without digital signatures, you might as well add deniability, such as in "Off the Record", the widely used IM privacy plugin - http://otr.cypherpunks.ca/ - elliptic Curve makes people nervous - too much depends on the secret sauce of picking the right numbers and curves. - Elliptic curve is a patent minefield - despite djb's assertion to the countrary - hardcoding cryptographic ciphers and hashes is bad practise.
Really, at this point, let's fix it once and for all, for all protocols, not just http. We have DNSSEC now around the world, and in the .com in two years. Let's not build another PKI infrastructure to distribute crypto identities. Let's not commit to a single cypher.
All these things have been discussed forever at the IETF - for better or for worse - these debates took their time for very valid reasons.
Paul Wouters, an IPsec Openswan developer