Do you know why I don't use TLS? Because getting a certificate is almost impossible for me and definitely not worth the hassle. I live in Iran, which as you may know is subject to financial and technological sanctions. It makes it impractical for us to buy anything from foreign countries because:
1. Because of the financial sanctions, it's nearly impossible to send money abroad. We can't have a wire transfer from our bank account to another country. We can't open an account in a foreign bank. We can't get an international credit card or open a PayPal account (as a matter of fact, PayPal has banned Iranian IPs. We can't even open the website).
2. Even if we somehow manage to send the money, we cannot expect a reliable service. More than once have tech companies, especially hosting providers, closed the account of all Iranian customers citing regulations. We try to stick to .ir domains or at least have one as fail-safe, use primarily Iranian hosting providers despite their much higher prices and avoid relying on foreign services at any cost.
I've seen here on HN that some people say cost is not prohibitive in adoption of TLS. It's only <single digit number> dollars on <CA name> after all. The cost is not the problem here. The act of paying is a barrier to entry for many people. That's why my university has a supercomputer, but you'll get an SSL error when you visit its website because it's self-signed.
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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
So the discussion is not "moot". If you run a website or webservice that must be secured -- you need to secure it or not host it.
As an aside -- I don't believe Iran is currently under UN sanctions -- I believe they expired at the beginning of 2014 [1] ... the US, and several EU countries and others still do have Sanctions, sure... but it's not the entire world... specifically China and Russia are not on the Sanctions list, and both operate public CA's.
I said it was moot unless you could point us to a CA that would (1) sell to Iran and (2) be accepted in most browsers. I'm still not sure if someone in Iran can actually buy from this CA - 10-100x markup aside - as there doesn't appear to be an online purchase ability. The website has also not been updated in 2 years. One final issue is that this is a reseller of TURKTRUST, which was pulled from all major browsers last year due to their major screwup allowing people to impersonate Google. They're back in the browsers, for now, but we'll see how it unfolds in the future.
Multiple UN sanctions against Iran are still in effect. Some relief was granted in December 2013 but most of the sanctions regarding oil, banking, and finance remain in effect. Wikipedia is often out of date with regards to issues like this. It's an extremely poor source of information, but often helpful to find a reliable source from the footnotes.
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.
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.
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".
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.)
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 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?
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.
>> 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.
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.
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.
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.
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.
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).
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.
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.