
Is TLS Fast Yet? - jgrahamc
https://istlsfastyet.com/?
======
smnrchrds
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
StartSSL offers free class 1 certificates. Don't know if that's any use to
you.

~~~
smnrchrds
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.

~~~
Alupis
If you are not capable of affording at least a cheap-almost-free ssl cert in
order to protect your site's users, and given your site actually requires SSL
(such as secure account login, transactions, etc) you probably should not be
running the site.

SSL certs can be found for $1.99 per year sometimes from companies (that's
cheaper than it costs to run your server). Sure they are not the "name brand"
ssl certs like from Verisign that cost $300 a year -- but to a browser, SSL is
SSL (so long as the browser recognizes the trust chain).

If your country prohibits SSL's use -- then you really should consider _not_
hosting your site from within your country.

Security is not a joke.

~~~
JohnTHaller
smnrchrds isn't saying they don't have the money to pay for it. They're saying
they can't pay for it. Because they're in Iran, they can't get PayPal, a
foreign credit card, etc. So, while they could get this SSL for free, it would
be a security risk for them since they'd be unable to revoke it if it were
compromised because they have no way to carry out the transaction.

~~~
Alupis
Most countries have operating CA's... and not every country has sanctions
imposed against Iran -- so it is possible to get a cert even if you live in
Iran.

~~~
JohnTHaller
I'd wager smnrchrds has tried that route as well. I'd also wager that most
countries with CAs accepted worldwide likely obey the UN ratified Iran
sanctions. So, unless you can suggest a specific CA that is accepted by most
browsers that is headquartered in a country that does not obey the UN ratified
sacntions against Iran, this discussion is moot.

~~~
Alupis
Here is one company offering SSL certs to Iranians (albeit, very expensive,
but it's still possible to get):

[http://www.ouriran.com/sslservices.cfm](http://www.ouriran.com/sslservices.cfm)

So the discussion is not "moot". If you run a website or webservice that
_must_ be secured -- you need to secure it or not host it.

As an aside -- I don't believe Iran is currently under UN sanctions -- I
believe they expired at the beginning of 2014 [1] ... the US, and several EU
countries and others still do have Sanctions, sure... but it's not the entire
world... specifically China and Russia are not on the Sanctions list, and both
operate public CA's.

[1]
[http://en.wikipedia.org/wiki/Sanctions_against_Iran](http://en.wikipedia.org/wiki/Sanctions_against_Iran)

~~~
JohnTHaller
> So the discussion is not "moot".

I said it was moot unless you could point us to a CA that would (1) sell to
Iran and (2) be accepted in most browsers. I'm still not sure if someone in
Iran can actually buy from this CA - 10-100x markup aside - as there doesn't
appear to be an online purchase ability. The website has also not been updated
in 2 years. One final issue is that this is a reseller of TURKTRUST, which was
pulled from all major browsers last year due to their major screwup allowing
people to impersonate Google. They're back in the browsers, for now, but we'll
see how it unfolds in the future.

Multiple UN sanctions against Iran are still in effect. Some relief was
granted in December 2013 but most of the sanctions regarding oil, banking, and
finance remain in effect. Wikipedia is often out of date with regards to
issues like this. It's an extremely poor source of information, but often
helpful to find a reliable source from the footnotes.

------
danepowell
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...

~~~
Someone1234
> 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
I think by "certificate passwords" the poster was referring to the private key
associated with the TLS certificate and not the certificate itself.

------
cnst
Not fast enough yet:

[http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-
una...](http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-unauth-
enc-01)

[http://tools.ietf.org/html/draft-nottingham-
http2-encryption...](http://tools.ietf.org/html/draft-nottingham-
http2-encryption-03)

[http://tools.ietf.org/html/rfc7258](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!

------
thegeomaster
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.

~~~
ayrx
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](http://security.stackexchange.com/a/3213/10211)

~~~
thegeomaster
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.

~~~
ayrx
I have absolutely zero problems with experimentation, I like doing that as
well.

My primary concern is with people (and I'm not claiming that you are one of
them) publishing such experiments without huge "This should not be used in
production!!!" warnings and some poor fool deploys it and gets pwned 3 months
later.

TLS does have some overhead because of its flexibility, yes. But it's still
incredibly fast and should not be a bottleneck in most scenarios. Given that
it has been battle-tested with very little flaws found (most bugs are
implementation bugs, not protocol bugs), it is and will be for the foreseeable
future the #1 option for anyone looking for a encrypt-data-while-in-transit
solution.

------
d0ugie
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
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.

------
cm2187
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).

~~~
pornel
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.

~~~
cm2187
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.

~~~
rys
[https://www.startssl.com/](https://www.startssl.com/)

$60 one off payment to be verified, then you can issue unlimited wildcard
certs for any and all domains you control. i.e., the certs themselves are
free, you just pay for verification.

~~~
darklajid
I actually started that and stopped midway through.

The process was absolutely hostile, the requirements insane and I haven't
stripped like that, ever.

Plus, it's plain BROKEN (Really? Like, requiring a utility bill for
verification? What? Why?).

Obviously I didn't finish it (I did send most of my documents but stopped at
some point and told them that this is crazy, I don't care anymore), so my
advice might be crap. But I would advice everyone to avoid. this. process.

~~~
vacri
The process is hostile and the UI confusing at times, but the requirements
aren't insane. They're doing what they're _supposed_ to do: verify you are who
you say you are and that you're the owner of the domain. Just sending a mail
to the webmaster is weak verification (and a SPOF, if nothing else).

~~~
darklajid
I stand by my original argument.

A sane version in this country is PostIdent. It's a way to verify a person &
address using the post. Think postman arrives, asks you to pull out your ID
and sign something, hits okay. Company knows that you are a real person with
the specified name living at that place. They _might_ have access to the
number on your national ID afterwards, but I'm not even sure about that one.

Have you checked what kind of documents you're to send to a random foreign
company for verification?

On top of that, the process doesn't WORK internationally. I still don't
understand what kind of utility bills you have in Israel (StartSSL) or the US
(usually the source for.. things), but mine are different. Plus, what does a
random letter in a random language prove? Sending in an ID is understandable -
it's a state issued document and protected by law, forging one would be a Bad
Idea. A "utility bill"... Well, as I said: Insane. And arbitrary.

For the fun of it I looked up the mail exchange.

Documents they asked for (* denoting that I sent them):

\- Mobile bill

\- Utility bill* (sent a cable provider's bill)

\- Passport & ID *

(I think I provided my driving license as well)

The first two documents are absolutely braindead requirements. They certainly
don't have the expertise to know all utility providers/mobile network
providers on a global level. So I could hand in ANYTHING and it would a) be
probably legal (there's no law to prevent me from 'forging' a utility
bill.tell ..) and impossible to prove. That is .. unless they call your
utility/mobile provider to check the information, which wouldn't work in the
first place (data protection laws) unless you IMPERSONATE the person you try
to check. Which would be crazy on a different level.

In the end they wanted to send me a registered letter by snail mail and I
cancelled the whole ordeal. Doing that would've been an option of course, but
not after they asked for random documents proving my address. EITHER send me a
registered letter OR ask for crazy stuff that contains my name and address in
the header.

Plus, transparency. This whole process took a while and was a lot of "Now
please send this", "We really need that", "Since you have no mobile bill to
offer, we fall back to snail mails". I discovered this in painful mails, after
handing over enough of my data to do mostly anything in my name.

I fail to understand how this process could be acceptable and I certainly
consider it broken, hostile and inefficient.

(Handing in my utility bill was difficult as well - I blacked out all but the
letter head, which caused them to complain again and again. Ignoring that the
letter contained the SIP credentials for my landlines, what the..? I cannot
_invent_ a reason for this requirement. My creativity is too limited, it
seems)

~~~
vacri
A current utility bill shows a link to an address; a lot of IDs don't, and
from memory passports don't (anyway, they last for years and don't require
updates...). Yes, it's not foolproof, but it raises the bar. Most people have
access to this thing and are able to send it in - so it's a cheap way to raise
the bar.

Possibly you raised such a fuss that you tripped their 'possibly a forger,
probably not worth it' spider-sense, so you got more hoops to jump through.

~~~
darklajid
That's exactly my issue. Maybe that's the case in your country of origin, but
not here. The ID lists your address and you're required by law to update it
whenever you move.

Plus, they got that (address/name, a header of a utility bill), but complained
about blacked out passwords/details.

Plus, if your fallback is to send a registered letter to verify an address,
why .. not list that from the start and just do it that way? Slower, but less
crap.

We won't find some common ground here, of course. I don't think that I 'made a
fuss', not before the process became utterly broken and laughable.

------
higherpurpose
Can We Replace TLS Yet?

~~~
Someone1234
Sure! With what?

~~~
higherpurpose
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...](https://github.com/trevp/noise/wiki/Noise-properties-and-protocol-
comparisons)

[http://cr.yp.to/tcpip/minimalt-20130522.pdf](http://cr.yp.to/tcpip/minimalt-20130522.pdf)

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

------
castorio
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](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)

