Is TLS Fast Yet?

by jgrahamc • 12 years ago

99 113 12 years ago

cm21874• 12 years ago

The main problem isn't speed, it is the prohibitive cost of certificates and the low adoption rate of SNI (Win XP still isn't compatible).

pornel3• 12 years ago

I'm paying for certificates about as much as for domain names, and it's a small fraction of what I'm paying for hosting.

Win XP with non-IE browser supports SNI.

cm21874• 12 years ago

That's right. I remember that wikipedia was saying all browsers under XP but I just made a test and chrome is compatible. Still I suspect that most users who are still using XP either don't have a choice of browser (locked down corporate environment) or aren't sophisticated enough to worry about changing browser. And XP usage is still shockingly high.

The cheapest wildcard certificate I can find is £99 per annum. No matter the security requirements I just do not believe it costs that much to run this service. I suspect that we have a bit of a cartel there.

cnst8• 12 years ago

How many domains you have?

If you have 2 domains, and no subdomains, that might as well be the case.

If you have more than a couple of domains, certificate costs can go up exponential -- it's 10$/year for a single domain cert, but 50$/domain/year for a multidomain one.

I have maybe about a dozen or two of active domains; I cannot afford to have my domain costs go up exponentially all for some thin air.

robin_reala• 12 years ago

Win XP isn’t receiving security updates at all, not getting a secure connection is the least of its users worries.

rplnt• 12 years ago

Win XP isn’t receiving security updates at all

Just a note, MS already made (at least) one exception to that.

mike-cardwell• 12 years ago

People running IE on Windows XP already have a seriously degraded experience of the web. All that not supporting SNI means is that they'll get a certificate warning. It wont actually prevent them from accessing the HTTPS site. And to be honest, their machine is probably compromised anyway, so you shouldn't want them on your site in the first place.

I suspect the vast majority of sites wouldn't fair too badly from rolling out SNI today.

d0ugie• 12 years ago

What about somehow incorporating QUIC into this? Could that possibly cut down on a round trip or two here? Seems there is a lot of promise to that protocol, but not much news about it.

AlyssaRowan• 12 years ago

Results are currently mixed: ask Google. More work needed on UDP flow-control versus state-of-the-art TCP, and it seems to suffer badly on some ISPs without any clear clue why (probably anti-P2P throttling, is my guess?).

Might end up influencing a future DTLS, but there's no roadmap that far ahead and the WG isn't chartered to discuss overhauls or big changes, according to the chairs: if we need a TLS 2.0, we're probably going to need a tls-ng Working Group with a more open-ended remit.

We're doing our best to get rid of the worst baggage from TLS 1.3: only forward-secure ciphersuites using AEADs (AES-GCM, ChaCha20-Poly1305 which is in CFRG consensus call now, etc), a... lively discussion about renegotiation, client authentication, key rollovers and plain DHE given the "triple handshake" vuln... a better PRF and handshake, maybe (Triple-DH?)? Still in progress. It's mostly going to be a big tidy-up I reckon, much like LibReSSL is for OpenSSL!

Curve25519 for ECDHE has a draft and is being discussed right now. I'm ready to implement and looking forward to it - big speed boost!

PKIX lags behind, however, and is one of the more dangerous parts to implement (ASN.1 and friends). Certificate handling is a real bitch to get perfect, and there's a lot of inertia: Ed25519 would be wonderful, but even ECDSA certs are rare as hen's teeth right now (not that I'm a fan of ECDSA as it's a nightmare to get right - see recent BoringSSL patches). A wholesale replacement is unfortunately way out of scope: too much baggage.

youngtaff• 12 years ago

There are some lessons from QUIC that are being incorporated into TLS e.g. it was proved that one round trip could be removed (will see if I can find the actual detail)

thegeomaster7• 12 years ago

I'm currently writing a server-client secure architecture, an alternative to using HTTPS APIs that should work particularly well with mobile apps.

You acquire apps from a store (a trustworthy source) so you can assume that data hasn't been tampered with. Hence you can include with the app files a server certificate and a fallback certificate, and you can use that to securely authenticate with the server.

I'm trying to keep the overhead far lower than TLS (currently, for session resumption only ~210 bytes need to be exchanged for a functional connection), and alleviate the financial burden of TLS certificates (you pay the cost of secure delivery to the store, anyway). RESTful APIs should be pretty straightforward to translate to this model.

Apps today use HTTPS for secure calls to the API, and I think it's highly unnecessary to have the overhead of certificate presentation, cipher negotiation, and even the HTTP header for what is often as few as 40 bytes of request/response data.

Currently the server seems to perform extraordinarily well: I'm running a PHP backend and have a request-response model, like HTTP does, and I'm working on optimizing it to the levels of lighttpd, because I know it's possible. My point is that a reasonably secure specialized protocol can be made more efficient than TLS, especially when you know what you are always connecting to.

jacquesm• 12 years ago

Are you going to open the source on this?

thegeomaster7• 12 years ago

Yes, sure, I'm thinking a BSD-like license. I'm using libuv for the event loop and sockets on the server and OpenSSL for cryptography. So far (besides the server and client running on Linux) I have a proof-of-concept client app for Android, but as soon as I get my hands on an iPhone or Windows Phone device, those ports will be done, too.

ayrx2• 12 years ago

You do realize that using TLS doesn't necessarily imply that you require the overhead of certificates and ciphersuite negotiation?[0]

Given how difficult implementing TLS securely already is, I'm highly skeptical that you will be able to come up with anything that's faster and more secure than TLS especially since it won't be receiving peer review from trained cryptographers.

[0] http://security.stackexchange.com/a/3213/10211

thegeomaster7• 12 years ago

Implementing TLS securely owes its difficulty partly to the variety of ciphersuites and optional features that all need to be securely implemented. Building a simpler protocol which suites some specialized needs will make the number of ways in which you can screw up considerably smaller.

The StackOverflow answer you are linking to suggest hardcoding the server public key in the client (as was my idea) and then throwing away the whole server certificate. This means that the server wastes its precious time to send an X.509 certificate which the client will essentially discard (and it will add to the packet size, too). My protocol is currently very similar to TLS_RSA_WITH_AES_128_CBC_SHA256 mentioned in the answer. I'm using RSA, AES-256 in CBC mode, and SHA-256 HMAC authentication. I'm thinking of maybe switching from AES-CBC+HMAC to AES-GCM, but modifications to the protocol won't be hard if I get everything up and running smoothly.

I am, too, highly skeptical that I will come up with anything that is both faster and more secure than TLS. That's why I am open-sourcing it and not even thinking about trying to profit from it. I'm doing this for my own satisfaction, and if that results in something that will help others, that would be even better.

I don't have a problem with using TLS for secure communication in the client-server API case, but also with stuffing HTTP up there. This requires people to run a web server that will serve the API calls, and I conjecture that there is non-trivial overhead of the call going through the HTTP layer and getting dispatched to a script interpreter. And the cost is twofold because the response must get back from the interpreter, to the HTTP layer, augmented with an ASCII header and sent back through the TLS layer to the client application.

As part of this, since the scripts on the server are PHP currently (but with an ability to change this fairly easily), I'm working on a more lightweight FastCGI alternative that sacrifices some of FastCGI's aspects (such as running the FastCGI daemon on one host and calling into the scripts from another) but dispatching a request to a PHP instance (which I keep preforked, with a couple of spare ones, much like Apache does for its own processes) is essentially a zero-overhead operation.

I'm trying to be as secure as I can, attempting to mitigate timing and other side-channel attacks as much as vulnerabilities in the protocol itself. That's why I'm reusing a lot of the TLS ideas, but working in my own down there. I'm going to try to get trained cryptographers to review both the protocol and the code, but I don't aim to provide any warranty.

I'm aiming to build a better solution not for TLS, but for secure HTTP RESTful APIs when the client can know server information beforehand. It's a lot narrower use case and I think I can tackle it more effectively, and if it turns out to be a dead end, I'll have some experience on my hands. And the server I'm building is highly modular, so some parts (especially the threadpooled libuv-based protocol-agnostic backend) may be reused later if deemed appropriate.

lucian1900• 12 years ago

Since you're shipping certs with the app anyway, why not use a TLS library? Your own protocol is a lot less likely to be correct.

thegeomaster7• 12 years ago

Because building something like this is a neat challenge.

That's not the sole reason; see my reply to your sibling comment for some of my arguments in favor of this.

rakoo• 12 years ago

Hence you can include with the app files a server certificate

For more flexibility, you can include your own CA certificate, which you use to sign your servers' certificate, so that you can add/remove them without needing to update the app.

I think it's highly unnecessary to have the overhead of certificate presentation, cipher negotiation

If you (as a user) are really strict about privacy/security, or if you exchange a lot of information with the server, the benefits of TLS (or any security scheme for that matter) will outweigh the drawbacks soon enough that you will not think of it as a problem.

what is often as few as 40 bytes

Your credit card number is only 16 bytes, but I guess you want to securely transmit that :)

thegeomaster7• 12 years ago

For more flexibility, you can include your own CA certificate

This would require the server to present a certificate to a client. With that, I might as well be creating a TLS clone. So I'd like to avoid that for the sake of simplicity, at least for the first versions. I'll see where it goes from there.

If you (as a user) are really strict about privacy/security, or if you exchange a lot of information with the server, the benefits of TLS (or any security scheme for that matter) will outweigh the drawbacks soon enough that you will not think of it as a problem.

I was referring to cipher negotiation and certificate presentation, both of which, in my case, are in theory unnecessary to have security as strong as provided by TLS.

Your credit card number is only 16 bytes, but I guess you want to securely transmit that :)

I never said I wanted to sacrifice security for the 40 bytes, I was just saying that the HTTP overhead and TLS overhead is really a lot, and if I can get away with a specialized protocol with a lower overhead, that would be even better :)

jwarkentin4• 12 years ago

If you're not bothering with the HTTP protocol then you don't even need a certificate at all. You just need to have something like SSH's 'known_hosts' file. All you need to know when initiating communication over a secure channel is that the key the server sent you is in fact the key for the server. In fact, if you're including something with the app, just include the servers public key directly. Forget the whole key exchange process. Then use the server's public key to send a symmetric key generated by the app itself (sort of like TLS does) for the duration of the connection. This provides forward secrecy as well. Simple. Elegant. Secure.

The only catch is that if you change the server's key it will break all clients. However, you could always hard code a second public key that isn't even contained on your servers that is used as a fallback for catastrophic incidents where your private key gets exposed. Once you fix your security hole you swap out your key to your fallback and clients are secure again.

thegeomaster7• 12 years ago

Actually, when I said 'certificate', I actually only meant the public key, that's basically what you were describing. I rely on RSA-OAEP to detect if someone's been trying something funny (I've been told on StackExchnage Crypto that I can rely on it to tell me if a message I'm decrypting was encrypted using a non-matching public key). However, sending a client-generated symmetric key using the server's public one is not perfectly forward-secret: namely, if a server's key ever gets compromised, prior recorded communication can be trivially decrypted. I want to minimize the damage done if a server key is exposed.

Furthermore, a compromised pseudorandom number generator on the client can compromise the security of communication. To mitigate that, at least partly, both parties in my scheme contribute half of a session AES key.

danepowell• 12 years ago

I don't think the biggest hurdle with TLS adoption is performance- it's the added complexity of integration with load balancers, reverse proxies, mixing of HTTP/HTTPS content, having to manage certificate passwords and enter them whenever you (re)start a web frontend, etc...

Someone12347• 12 years ago

manage certificate passwords and enter them whenever you (re)start a web frontend

People do this? First I've ever heard of it. In fact most of the software I've ever used doesn't even support PKI passwords and instead will just tell you the certificate store is corrupted.

porpoisemonkey• 12 years ago

I think by "certificate passwords" the poster was referring to the private key associated with the TLS certificate and not the certificate itself.

jwarkentin4• 12 years ago

mixing of HTTP/HTTPS content

This is ALWAYS a bad idea. A few points:

- The only purpose of HTTPS and encrypting communications in general is to prevent MITM attacks.

- If your server is even willing to serve unencrypted requests it exposes your users to sslstrip attacks (http://www.thoughtcrime.org/software/sslstrip/). In reality you still should serve HTTP requests but only to force a redirect to HTTPS. In addition you should use the 'Strict-Transport-Security' header. It's the ONLY way to prevent future sslstrip attacks.

- Even worse, if you don't set the 'secure' flag on session cookies at a minimum (thus forcing logged in users to HTTPS only) you expose your users to session hijacking without even putting up a fight.

- If you aren't going to bother with forcing HTTPS all the time then there's not much point as you've opened up your users to simple sslstrip attacks followed by session hijacking or even worse, script injection or redirects.

One fundamental concept many people seem to forget as well is that the dangers of not encrypting communications extends beyond snooping. Attackers can actually modify the data stream to inject and/or replace content or even redirect users entirely.

Also, even if you only serve secure content yourself but you include insecure content on your page it exposes security vulnerabilities. Let's say you include unencrypted images on your site and you have users that are using a client with an image rendering engine vulnerability that allows remote code execution (this has happened in about every browser). All a MITM has to do is replace the requested image with different content that exploits the vulnerability. Now imagine if you included unencrypted JavaScript that actually does execute on your site (like from a CDN). The possibilities are endless.

smnrchrds2• 12 years ago

Do you know why I don't use TLS? Because getting a certificate is almost impossible for me and definitely not worth the hassle. I live in Iran, which as you may know is subject to financial and technological sanctions. It makes it impractical for us to buy anything from foreign countries because:

1. Because of the financial sanctions, it's nearly impossible to send money abroad. We can't have a wire transfer from our bank account to another country. We can't open an account in a foreign bank. We can't get an international credit card or open a PayPal account (as a matter of fact, PayPal has banned Iranian IPs. We can't even open the website).

2. Even if we somehow manage to send the money, we cannot expect a reliable service. More than once have tech companies, especially hosting providers, closed the account of all Iranian customers citing regulations. We try to stick to .ir domains or at least have one as fail-safe, use primarily Iranian hosting providers despite their much higher prices and avoid relying on foreign services at any cost.

I've seen here on HN that some people say cost is not prohibitive in adoption of TLS. It's only <single digit number> dollars on <CA name> after all. The cost is not the problem here. The act of paying is a barrier to entry for many people. That's why my university has a supercomputer, but you'll get an SSL error when you visit its website because it's self-signed.

danbee• 12 years ago

StartSSL offers free class 1 certificates. Don't know if that's any use to you.

smnrchrds2• 12 years ago

I'm aware of that, but because revoking the certificate is not free, it would be impossible for us to do. Not very good security-wise.

Someone12347• 12 years ago

They're only usable for non-commercial purposes. So for an *.ir business, it remains problematic.

dspillett• 12 years ago

Though be wary of the "non commercial use" clause on the free certificates. I have no idea how, or indeed if, they enforce that (revoking the certificate if they find you using it for commercial purposes?) but it is there.

cnst8• 12 years ago

StartSSL offers free class 1 certificates. Don't know if that's any use to you.

No, that doesn't work.

0. Once you go https, you're basically hooked. What if StartSSL stops offering free certs tomorrow? They've been offering free certs for ages now, yet still have no competition! So much for the free market.

1. What if you have a good dozen of different domains? The cheapest multidomain certificates seem to start 50$+/domain/year, that's a pretty hefty price tag for non-commercial projects.

We need something like STARTTLS in smtp/xmpp/etc for http, which just protects the traffic from eavesdropping and passive attacks. Because right now as it is, from the user's experience, having a self-signed https is WORSE than not having any https at all. Do you get any warnings on http web-sites? What about self-signed https? WTF?

I don't live in Iran, but I completely agree with the OP that TLS is not ready yet, by not being affordable and dependable.

I'll adopt TLS for http as soon as, (1), I can guarantee that existing users won't suffer, (2), I won't be required to update certificates all the time (when was the last time you've updated your ssh certs?), (3), I won't be required to pay hundreds/thousands of dollars (per year) to secure all my domains.

castorio4• 12 years ago

self-signed is as good as CA-based from a security-POV. it's just that the browsers complain.

Nursie4• 12 years ago

It absolutely is not. With CA based you have an existing trust relationship to build on. It may be a flawed one but it is there.

Asking a client to accept self-signed is asking for a MITM attack.

Someone12347• 12 years ago

You lose 50% of the benefit of HTTPS then. It is 1/2 about encryption and 1/2 about interception/impersonation/MitM protection.

The only way to do a self signed cert while maintaining all of the benefits is to have the client install your root CA into their CA store. However for the user to do so they have to fully trust you and your security (since for all they know you could generate fake certificates for Microsoft, Google, Amazon, etc that would show up as legit for them (certificate pinning aside)).

I really REALLY dislike the current HTTPs/SSL/TLS system, the fact that money and hassle is a literal cost to security is a huge problem. However self-signed certificates aren't remotely a solution.

y0ghur7_xxx4• 12 years ago

We should really work towards eliminating the need for CAs (or any central authority for that matter).

http://convergence.io/ is (was?) a great idea and technical implementation of it, I installed two notaries on two different servers I own, and it worked great. It seems dead now. Don't know why.

higherpurpose4• 12 years ago

Moxie has said they are waiting on browsers to implement TACK.io, but not entirely sure why tack is needed for Convergence.

AnthonyMouse4• 12 years ago

In theory DNSSEC should replace the CAs for domain validated certificates. The problem is that most clients don't support it (and there are currently some nontrivial reasons for that).

What would be great is if somebody (I'm looking at you, Google or Mozilla) with the clout to get their CA cert trusted could set up a free website that would validate DNS TLSA records with DNSSEC (or DNSCurve if you like) and then automatically sign the certificate from the DNS record with the CA key. That should be at least as secure as domain validation with email, and a lot easier to do. Then you could put that cert on your server and use it for all the clients that don't support DNSSEC, and relegate DNSSEC and all its problems to just providing strong proof to the CA that it's signing the right certificate.

Combine that with certificate pinning and it should pretty well solve the problem, and leave CAs to the job they should have had all along, which is providing extended validation certificates for banks and the like.

jwarkentin4• 12 years ago

http://okturtles.com/

higherpurpose4• 12 years ago

You should create .dns or .bit domains and encourage Iranian users to use DNSchain servers for DNS:

https://github.com/okTurtles/dnschain

comex• 12 years ago

Not that it's as good a solution as replacing the CA system, but you could try mining one of the cryptocurrencies (not Bitcoin, since it's dominated by ASICs) on a GPU - I guess at significant loss compared to the cost of electricity these days, but allowing you to get a little money without having to deal with financial regulations. And then buy services anonymously through Tor.

mrb• 12 years ago

Financial sanctions? Buy a certificate from Namecheap and pay using Bitcoin (yes they officially accept it!) In Iran, you can obtain coins through https://localbitcoins.com/country/IR or http://www.coinava.com/

This is a very concrete example demonstrating how Bitcoin is resistant against censorship, sanctions, etc.

_delirium• 12 years ago

Wouldn't Namecheap still refuse the transaction? Afaict, Namecheap is a U.S.-based company, and would be violating the law if they did business with an Iran-based company (regardless of the medium of payment).

wyager• 12 years ago

It's worth pointing out that we have viable technical solutions to Zooko's triangle (allowing for secure, decentralized, human-friendly web security).

I hope sooner or later, solutions like namecoin are actually widely implemented.

higherpurpose4• 12 years ago

Can We Replace TLS Yet?

Someone12347• 12 years ago

Sure! With what?

higherpurpose4• 12 years ago

Noise or MinimaLT. Noise is mostly concept right now, though, but MinimaLT implementation is coming later this year:

https://github.com/trevp/noise/wiki/Noise-properties-and-pro...

http://cr.yp.to/tcpip/minimalt-20130522.pdf

CurveCP also already exists. And there's this, too: http://tcpcrypt.org/

castorio4• 12 years ago

what do you mean by "Fast"?

from what i've learned with webservers it depends on implementation: cipher-suites, keep-alive, session-ticket-reusage etc. this pic shows the perfomance for a webserver w/ different cipher-suites: https://8ack.de/static/bimages/ssl_perftest_r1.jpg

speaking of webservers, if you use the usual performance-tweaks you wouldnt see a big performance-drawback from userperspective (YMMV)

cnst8• 12 years ago

Not fast enough yet:

http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-una...

http://tools.ietf.org/html/draft-nottingham-http2-encryption...

http://tools.ietf.org/html/rfc7258

So, it turns out, someone IS finally seriously working on opportunistic encryption for HTTP like STARTTLS is to SMTP!

Looking very forward to when it'll hit the streets!

Is TLS Fast Yet?

Related Stories