Is TLS Fast Yet?
istlsfastyet.com
istlsfastyet.com
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.
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.
If your server requires SSL due to security reasons, and you are not capable of using SSL for one reason or another, then I'd rather you don't run that server at all.
Besides, if it's not an cost-prohibitive problem, but rather one can't get an SSL cert due to sanctions, etc... well, that argument doesn't hold water either. Not every country holds sanctions against Iran for example. You may not be able to get an SSL cert from a USA company, but there are many other countries who have CA's available that probably have no sanctions.
In the end, security is not a joke. If your server requires itself to be secure, you'd better do it.
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.
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.
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.
In fact, if you are on a modern browser, look at the SSL cert HN is using -- it should show you are using TLS 1.2. -- so no users "suffer".
Some SSL certs have become bloated in price (without good reason), such as the VeriSign certs, etc. No SSL cert should cost $300 a year... that's absurd. However, they can't be free... someone has to pay for the infrastructure that not only signs certs, but provides the trust backbone that SSL rides on.
No, once you go SNI and people start sharing https links, you basically cut off all users who have older browsers. Which is complete bullshit -- they should just be getting the non-encrypted web-site, just like what happens with smtp and STARTTLS.
> No SSL cert should cost $300 a year
Yet you won't find a cert for a dozen different domains cheaper than 600$/year. And what if you want to wildcard each of those domains, too?
> someone has to pay for the infrastructure that not only signs certs, but provides the trust backbone that SSL rides on.
And I should care about the trust backbone for my personal web-site and non-commercial projects why exactly?
You don't have to. Issue a self signed cert and provide instructions to add it to the browser as a trusted certificate authority. The fact that no one trusts you by default becomes your problem, the alternative is caring about the trust backbone (or I suppose, paying Microsoft, Apple, Google and Mozilla to add your CA, but I would guess that will run a bit more than $600/year.)
The issue everyone seems to be ignoring is that PEOPLE ALREADY TRUST HTTP!
They ALREADY trust my http web-site! All of them, on all domain names, and through all redirects!
Why should I take extra steps for them to lose such trust through adopting https? Why?
There is no economic benefit for me to add https. None. As much as I'd like to contribute to encrypting the whole internet, the whole https concept (with no backwards compatibility with http) is just too much trouble to deal with.
If you are just serving up hobby projects and personal stuff, there's probably no economic benefit to hosting it yourself anyway.
If their ISP is injecting banner ads, then all bets are off! Nothing I can do about it! They should change ISPs, or browse through a proxy.
Or are you supporting the concept of fast lanes in the net neutrality debate? I should pay up to the CAs to get treated more preferentially by the ISPs?
> If you are just serving up hobby projects and personal stuff, there's probably no economic benefit to hosting it yourself anyway.
Yeah, right! Now I'm suddenly guilty of hosting my personal stuff myself! Maybe I should ask Comcast or AT&T to host it for 3x the price I pay by hosting myself on a cheapo dedi?
What? They don't offer https, either?!
Asking a client to accept self-signed is asking for a MITM attack.
To use an analogy: One could make the statement that a kevlar vest doesn't protect you from bullets, then cite an example when a military grade round went through one and killed a cop. However this statement would be equally misleading to yours, as we all know a kevlar vest is better than nothing and that it will stop a typical street bullet (e.g. handgun round).
Furthermore, the "trust relationship" between a user and a CA is based on nothing more than the CA's sayso. Do you personally trust every cert that your browser does? What about your OS? Trust that they'll never issue a cert they shouldn't? Trust that their operations are secure?
And finally, the self signed CA still protects against passive monitoring and eavesdropping, which I'd say is a much more clear and present threat.
There are literally governments which have used a fake certificate to monitor SSL connections. It wasn't detected for quite a few months.
The average user will probably not be MITM'd. There simply are too many users and not enough attackers. Additionally, the attacker must hit the user during their first visit to the site or never.
Either way, self signing is not as secure as using a CA and it is not just browsers being picky.
And then it's still no worse than self signed even in the worst case.
Trust is not a commodity to be exchanged by money!
Nope. I'm saying nothing of the sort. I'm saying that if you do not have an existing trust relationship then bootstrapping one over a public channel is asking for trouble. Third parties happen to form a part of the solution we use for https. It is a flawed model and it is rife with problems.
But it's better than not having it at all.
So yes, you are playing with fire if you trust an SSH host on first view. You will get protection against someone changing the signature later, but you have no protection against a malicious MITM player who is well resourced. Like, say a government that can insert themselves at various ISPs and do what they like with your traffic.
>> Trust is not a commodity to be exchanged by money!
It's up to you to decide what trust is. What it is not is blindly trusting that nobody out there is performing an MITM on your data.
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.
convergence might have been an interesting approach, but i did not heard much of it lately http://convergence.io/
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.
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.
DNSSEC still has a central trust anchor that signs the records. Convergence is completely distributed.
Convergence also requires client support on all the clients before you can stop using CA-signed certificates, which isn't going to happen quickly. A CA (or someone who bought an intermediary CA certificate from an existing CA) could set up the thing I described in a matter of hours and henceforth anybody who needs a domain validated TLS certificate could get one instantly, securely and for free by just adding a DNS record and visiting that website.
Notary requests use TLS too: If an attacker redirects my requests to other (untrusted) notaries my client will complain because it has the (self-signed) certs of the notaries cached. I can buy two or more servers in different counties, install the notary server on them, copy&paste the cert of the notaries in my client, and from that moment on Convergence works and my TLS connections are secure.
> Convergence also requires client support on all the clients before you can stop using CA-signed certificates, which isn't going to happen quickly.
Clients that use Convergence are effectively CA free from the moment they install it. The others can follow incrementally.
> A CA (or someone who bought an intermediary CA certificate from an existing CA) could set up the thing I described in a matter of hours and henceforth anybody who needs a domain validated TLS certificate could get one instantly, securely and for free by just adding a DNS record and visiting that website.
Notary certs are self signed. A browser vendor could set up a few notary servers that use certs they signed themselves and ship with them by default. Browser vendors already ship with the CA certs, so instead of the CA certs they would ship with their own cert that signed the ones the notaries use. If you don't trust them use your own notaries no problem. Everything works like before. I just think it's an awesome idea.
In other words, the servers have to keep using CA certificates for however many years it takes for the rest of the clients to "follow incrementally." Hence what I'm proposing.
> Notary requests use TLS too: If an attacker redirects my requests to other (untrusted) notaries my client will complain because it has the (self-signed) certs of the notaries cached. I can buy two or more servers in different counties, install the notary server on them, copy&paste the cert of the notaries in my client, and from that moment on Convergence works and my TLS connections are secure.
You misunderstand. The problem is not for the client when the attacker controls a DNS resolver, the problem is for everybody when the attacker controls a DNS TLD. You're trying to verify the certificate for democracy.cn which is supposed to resolve to 1.2.3.4, but China changes its DNS record so that it points to 6.7.8.9 which is the Chinese government's MITM server. Now you go out and ask ten thousand notaries, what's the certificate for democracy.cn? They all resolve it to 6.7.8.9, get the attacker's certificate from China's MITM server and tell you they all saw the same certificate. But it's the attacker's certificate.
The existing CA system doesn't solve this. The attacker that can control a TLD is the sort that can control a CA. But you're claiming Convergence would fix it, which is a misunderstanding of what Convergence does. Convergence is solving an entirely different problem.
The thing that (mostly) fixes it is certificate pinning. It doesn't fix it if the attacker starts the attack as soon as the server is put online (which is about a thousand times harder for the attacker to do than the status quo), and I'm not actually sure how they deal with certificates legitimately changing over time, but certificate pinning really does go a long way to preventing any central authority from being able to MITM arbitrary connections.
I see your confusion because Moxie Marlinspike is the one advocating both certificate pinning (i.e. Tack) and Convergence and you can use them together. But there is no technical reason you couldn't also use certificate pinning in combination with DNSSEC. Or use all three together, essentially using the DNSSEC signed certificate as an additional notary.
The existence of Convergence as something cool we should all be using ten years from now doesn't mean we don't still need transitional measures in the meantime. Moxie is playing the long game. If you want to do something today then you need to somehow deal with all the clients that don't support it yet.
Yes I did. Thanks for clarifying.
> The existing CA system doesn't solve this.
So that's why Moxie is pushing for TACK. Now I understand how all works together.
> The attacker that can control a TLD is the sort that can control a CA. But you're claiming Convergence would fix it.
No I don't. I didn't even think about that scenario.
Thanks for the discussion. HN is awesome.
This is a very concrete example demonstrating how Bitcoin is resistant against censorship, sanctions, etc.
I hope sooner or later, solutions like namecoin are actually widely implemented.
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.
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.
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!
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.
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.
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.
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.
That's not the sole reason; see my reply to your sibling comment for some of my arguments in favor of this.
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 :)
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 :)
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.
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.
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.
Win XP with non-IE browser supports SNI.
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.
$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.
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.
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)
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.
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.
And I am the first to deplore that.
StartSSL can make the certificate for free because their infrastructure is all automated. You don't know if certificate revocation requires human intervention or not.
Plus certificate revocation is useless in case of MITM. Browsers need to be able to contact the certificate authority and will just ignore it on timeout. So the only difference is that the MITM has to blackhole the CA on top of the usual routine.
All you can do is hope nobody stole your SSL certificate.
You can get $9 certs from namecheap: https://www.namecheap.com/security/ssl-certificates/comodo.a...
The cheapest wildcard certificate I can find is £99
per annum.
[1] https://cheapsslsecurity.com/comodo/positivessl-wildcard.htm... [2] https://www.ssl2buy.com/cheap-wildcard-ssl-certificates-ads
$45/year (£26.42/year)
76 USD/year which is about 45GBP per annum.
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.
Oh, you need multiple IPv4 addresses for that? Just buy them, SSL is a valid jusstification for consuming IPv4 addresses. It's also a lot cheaper than multidomain certificates. Again, the cost increase is only O(N), not exponential.
If it costs you more than $150/year to secure a dozen domains, each with its own IPv4 address, it's not because you're being ripped off, it's because you didn't do your homework. The very fact that some companies can still get away with selling $500 certificates in a purportedly free market implies that most people aren't doing their homeworks.
Plus, are you suggesting that I even get separate certificates (and IPs!) for subdomains? Because I don't actually have to pay anything for my own subdomains to anyone! (Other than the https certificate companies, apparently.)
Plus, having to manually re-install all of these certificates every year? No, thanks! Fix it first! I don't have to re-install my STARTTLS in SMTP, noone gets any self-signed warnings, yet all my email is still immune from passive eavesdropping or any kind of passive tapping of the traffic.
Besides, it was your choice to get a dozen different domains and create a bunch of subdomains on them, instead of, say, subdirectories. You should have been fully aware of the costs and limitations of existing protocols and market conditions when you did that. It's also entirely your choice whether or not to support non-SNI clients. Some of us stopped supporting IE8/XP a long time ago, some of us keep supporting it at a significant cost (often many thousands of dollars). Either way, it's your choice.
Every choice has pros and cons to it. No use complaining about it because you happened to choose a less widely supported and more costly option. Hell, I'd love to get a thousand different domains and an entire /20 for personal use. Why should I pay $10K/yr for my preferences?
If you don't want to pay for overpriced certificates on your gazillion subdomains, just don't. Consolidate your domains and subdomains, or at least consolidate the parts that need SSL. It's as simple as that. If nobody ever fell for the wildcard and/or multidomain certificate racket, CAs would have to price their products more competitively. Stop whining and start voting with your wallet, it's the only vote that matters.
Not sure on your math. 2EUR/IPv4/year is 24EUR/IPv4/year, say, you have just two subdomains -- that's already 48EUR/IPv4/year, for a single TLD domain!
> Besides, it was your choice to get a dozen different domains and create a bunch of subdomains on them
Yes, based on best practices and technological needs; or maybe consolidation of a legacy architecture (where each domain used to have a different physical machine); or maybe the future compartmentalisation through IPv6 (where each domain has a separate logical IPv6-only machine, all sharing IPv4 through a single non-fail-safe legacy proxy); or maybe just outright security for cookies between separate applications I run to protect against XSS attacks.
Or do you suggest I make my choices in technology based on the racketeering of the certification cartel instead? Use inflexible, stagnated and insecure operating practices just to please the certificate authority cartels? No thanks.
> your choice whether or not to support non-SNI clients
What did non-SNI clients did to you to block them from allowing access to your personal web-site? Android had no SNI support until very-very recently, for example. I don't want to not be able to access my own web-site from my own phones! However, the separate `https` address scheme would guarantee that my site wouldn't simply work if I follow someone's https link to it on my Android 2.2 device, and there is no way to avoid someone from giving out https links should I enable https (which will never happen, BTW).
> I'd love to get a thousand different domains
You can -- you don't have to pay anyone for your subdomains! Other than the certificate authorities, apparently!
> If you don't want to pay for overpriced certificates on your gazillion subdomains, just don't. Consolidate your domains and subdomains, or at least consolidate the parts that need SSL. It's as simple as that.
Aha! Parts that need SSL? It'd be nice to have, but none require it -- I'm not running a bank and don't collect payment details! And, no, I will not revisit sound engineering and marketing decisions based on the political limitations of the certificate authorities. Not gonna happen. CAs will not dictate the rules of the game for me.
Fix encryption for HTTP to be as easy as SSH and STARTTLS in SMTP (I don't need no https access scheme for my non-commercial pages!), and I'll gladly enable it for all of my domains. Until then, thanks, but no thanks.
$500 certificates are Extended Validation certificates that require man power to verify many details about a company. There are other costs involved in the certificate issuance process that is mandated by the CA/Browser forums.
There are multi-domain certificates for less than $100 that allow wildcard in the certificate. If you really knew what you were doing you would only need one certificate and it would cost less than the $150 you are talking about.
If you have an ecommerce site that Extended Validation certificate is worth it. Our sales increased by better than 40% by having an Extended Validation certificate. So YMMV. Do what makes the best sense for your site.
Self signed certificates are just as secure but they give the warning unless you import your CA certificate into your browser. So you can get away with free if the sites are only for internal use only pretty easily.
Just a note, MS already made (at least) one exception to that.
I doubt you'll see too many more XP security updates, that literally might be the last official one (unless you count packages which aren't intrinsically linked to the OS, like the .Net framework for one example).
I suspect the vast majority of sites wouldn't fair too badly from rolling out SNI today.
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/
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)