Is TLS Fast Yet?(istlsfastyet.com)
istlsfastyet.com
Is TLS Fast Yet?
https://istlsfastyet.com/?
8 comments
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.
This is a very concrete example demonstrating how Bitcoin is resistant against censorship, sanctions, etc.
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).
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.
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.
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.
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.
> In theory DNSSEC should replace the CAs for domain validated certificates.
DNSSEC still has a central trust anchor that signs the records. Convergence is completely distributed.
DNSSEC still has a central trust anchor that signs the records. Convergence is completely distributed.
I'm not sure how you think Convergence is going to remove the central trust of DNS: If the attacker has control of your DNS records then every one of the notaries is going to go to the wrong IP address to check the certificate and they'll all see the same (wrong) one.
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.
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.
> I'm not sure how you think Convergence is going to remove the central trust of DNS: If the attacker has control of your DNS records then every one of the notaries is going to go to the wrong IP address to check the certificate and they'll all see the same (wrong) one.
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.
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.
> Clients that use Convergence are effectively CA free from the moment they install it. The others can follow incrementally.
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.
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.
> You misunderstand.
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.
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.
Moxie has said they are waiting on browsers to implement TACK.io, but not entirely sure why tack is needed for Convergence.
TACK is supposed to be a backwards-compatible standard, Convergence is a replacement.
You should create .dns or .bit domains and encourage Iranian users to use DNSchain servers for DNS:
https://github.com/okTurtles/dnschain
https://github.com/okTurtles/dnschain
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.
StartSSL offers free class 1 certificates. Don't know if that's any use to you.
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.
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.
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.
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.
[deleted]
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.
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.
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
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://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
> 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.
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.
I don't think he was saying he couldn't pay because he couldn't afford to pay, I think he was saying he couldn't pay because he doesn't have the option of paying with the economic sanctions against Iran.
That does not change the spirit of my comment.
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.
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.
> 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.
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.
You do know TLS and SSL can be on the same server?
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.
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.
> 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".
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?
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?
> 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.)
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.)
> 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.
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.
How do they know they are getting your website? Do you care if their ISP is injecting banner ads and messing with your layout?
If you are just serving up hobby projects and personal stuff, there's probably no economic benefit to hosting it yourself anyway.
If you are just serving up hobby projects and personal stuff, there's probably no economic benefit to hosting it yourself anyway.
> How do they know they are getting your website? Do you care if their ISP is injecting banner ads and messing with your layout?
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?
https://comcast.net
What? They don't offer https, either?!
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?
https://comcast.net
What? They don't offer https, either?!
They're only usable for non-commercial purposes. So for an *.ir business, it remains problematic.
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.
[deleted]
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.
I hope sooner or later, solutions like namecoin are actually widely implemented.
self-signed is as good as CA-based from a security-POV. it's just that the browsers complain.
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.
Asking a client to accept self-signed is asking for a MITM attack.
Basically you're saying that I'm playing with fire with SSH because I trust a host on first view: everything not stamped by a third party is rogue.
Trust is not a commodity to be exchanged by money!
Trust is not a commodity to be exchanged by money!
>> Basically you're saying that I'm playing with fire with SSH because I trust a host on first view: everything not stamped by a third party is rogue.
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.
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 likelihood of any one user to be the target of a MITM is vanishingly small. Once that certificate has been accepted, they will be notified if it changes anyways.
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.
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.
Passive monitoring? Sure. Impossible to detect active monitoring? Also yes.
There are literally governments which have used a fake certificate to monitor SSL connections. It wasn't detected for quite a few months.
There are literally governments which have used a fake certificate to monitor SSL connections. It wasn't detected for quite a few months.
The difference being that we know the first one is happening right now.
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.
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.
The average user may well be MITMd by their own government. Doesn't seem that unlikely any more.
Either way, self signing is not as secure as using a CA and it is not just browsers being picky.
Either way, self signing is not as secure as using a CA and it is not just browsers being picky.
..in which case they'd just compel the CA to cough up a certificate. This does not apply, at all, to the argument for or against self-signed certs.
Depends on the government involved, and on the user, and on the authority.
And then it's still no worse than self signed even in the worst case.
And then it's still no worse than self signed even in the worst case.
MITM attack if trivial over wifi. And the Snowden files have shown that it is trivial for the NSA too. In fact it is routinely done by the middle-east dictatures to spy on their dissidents.
A self-signed certificate still has the revocation problem, though.
All certificates have the revocation problem. The revocation mechanisms have serious performance and reliability issues (e.g. what do you do if you can't contact the server?) which means that hardly anybody uses them and most people who do are doing it wrong.
Somewhat short lived certificates (two weeks?) solve most problems around online revocation. But on that timescale a self signed isn't terribly convenient, so you still need some kind of issuing authority / infrastructure.
using the CA-model in its current way doesnt protect you from MITM either. diginotar anyone? http://en.wikipedia.org/wiki/DigiNotar
It absolutely does protect you from MitM. Does it offer full proof protection? No. But it adds a barrier between you and being trivially hit with a MitM.
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).
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).
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.
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.
no, they arent a solution, but they arent a problem either. think ssh/know_hosts - file.
convergence might have been an interesting approach, but i did not heard much of it lately http://convergence.io/
convergence might have been an interesting approach, but i did not heard much of it lately http://convergence.io/
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...
> 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.
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.
> 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.
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.
I think by "certificate passwords" the poster was referring to the private key associated with the TLS certificate and not the certificate itself.
[deleted]
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!
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!
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.
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.
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
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
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.
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.
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.
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.
> 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 :)
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 :)
>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 :)
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 :)
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.
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.
That's not the sole reason; see my reply to your sibling comment for some of my arguments in favor of this.
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.
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.
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.
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.
You're correct about the forward secrecy. That's what I get for commenting at 2am. I was thinking about TLS where there can be a frequently rotating asymmetric key pair. The symmetric key in TLS isn't used for PFS, only for performance. In practice those keys don't actually get rotated almost ever though.
Are you going to open the source on this?
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.
Are you aware of: http://curvezmq.org/ ?
I wasn't. Thanks for the link. Besides the fact that it works on top of ZeroMQ and some differences in operation, it seems that it has roughly the same goals as me. Will look into the RFC for some ideas.
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.
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.
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.
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)
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).
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.
Win XP with non-IE browser supports SNI.
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.
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.
When you get a domain from gandi.net it's £11 (otherwise £31).
You can get $9 certs from namecheap: https://www.namecheap.com/security/ssl-certificates/comodo.a...
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
AlphaSSL resellers tend to be even cheaper:
http://www.garrisonhost.com/ssl-certificates/alphassl.html
$45/year (£26.42/year)
$45/year (£26.42/year)
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.
$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.
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.
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.
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).
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)
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)
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.
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.
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.
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.
I haven't tried this service. But I think it is fair to say that SSL certificates being as they are (complex and expensive), we will not see an all-https web anytime soon. SSL certificates need to be fixed first, it must be cheap and easy to set up SSL on a shared server with limited technical knowledge before we see it generalised.
And I am the first to deplore that.
And I am the first to deplore that.
Are they the outfit that screwed everyone over on heartbleed by charging a fortune to revoke certificates they had given out for free?
It's not like they invented the pricing during heartbleed, it was always out there.
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.
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.
Beware, they claim they will issue unlimited certs, but even after completing a domain validation via email to an admin account on the domain, they might refuse your cert if they care to look at the WHOIS data and decide it's not "you" (for example, a different business name or admin contact). They might even change their mind on this when you try to renew a cert they had previously issued.
And $25 to revoke. Miskey the CN? Cough it up. A bug in openSSL gets your private key owned? Pay up. Want a different type of cert for the same domain? Pay the man.
https://www.gogetssl.com/wildcard-ssl-certificates/comodo-po...
76 USD/year which is about 45GBP per annum.
76 USD/year which is about 45GBP per annum.
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.
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.
The cost of SSL certificates scales linearly, not exponentially, with the number of domains. Just buy a certificate for each domain and don't bother with the "multidomain" or "wildcard" rackets.
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.
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.
Why do you need multiple IPs when SNI is supported on most major operating systems and most server platforms. Just look on Wikipedia for a full list of technology that supports Server Name Indication. It is free.
$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.
$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.
IPv4 addresses are more like 2 EUR/IPv4/month now -- already more than twice more expensive than the domain names, plus, there is generally a limitation of, say, 8 or 16 addresses per non-enterprise hosting accounts. And these prices will only go up in the future!
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.
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.
I was just trying to point out that the cost increases linearly and nowhere near $50/domain/yr.
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.
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.
> I was just trying to point out that the cost increases linearly and nowhere near $50/domain/yr.
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.
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.
Win XP isn’t receiving security updates at all, not getting a secure connection is the least of its users worries.
> Win XP isn’t receiving security updates at all
Just a note, MS already made (at least) one exception to that.
Just a note, MS already made (at least) one exception to that.
That's true, however that was because the component they were updating also happened to exist on operating systems they are still currently supporting.
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 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).
They made an update for an IE-on-XP bug, probably because IE is an important brand for them right now and they didn't want a disaster in they news with IE all over it, even if it was an "unsupported" version.
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.
I suspect the vast majority of sites wouldn't fair too badly from rolling out SNI today.
Can We Replace TLS Yet?
Sure! With what?
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/
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/
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)
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)
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.