[simula67]

Sorry for asking a potentially dumb question : but is it possible for me to set up a domain name thecitibank.com and ask letsencrypt to issue me a certificate ? I can then create a login page to steal IPINs. Isn't that why we have humans in the loop for issuing certificates ?

[Russell91]

This comment is the exact perception about HTTPS that we need to change. It's not the job of HTTPS to say whether a website is safe or unsafe, good or bad. HTTPS should be the default communication protocol for every website, and lets encrypt move us a major step towards that by making SSL certificates free and trivial to set up.

[chetanahuja]

"This comment is the exact perception about HTTPS that we need to change. It's not the job of HTTPS to say whether a website is safe or unsafe."

Too late. The web industry has spent about 20 years training regular people to look for that green lock sign in the address bar and feel all warm and fuzzy about how safe the site is. You can post on hacker news all you want about what perceptions need to be changed. It's not going to change the ground reality. SSL, as practiced in the industry today with all it's historical baggage is fundamentally broken. There's no fixing it.

[XorNot]

Actually what's really broken is the way we've approached implementations. Recently I was trying to get a self-signed certificate for myself trusted by Python urllib3...I still don't know how to do it. It uses a completely separate trust-store. As does half a dozen other things on my system.

[goldman60]

Java is literally the worst as well. The Java truststore doesn't even have all the certs that every major browser supports. I'm looking at you StartSSL.

[vacri]

Green lock = EV cert. People are trained to look for the green, not for the lock - few people other than techies even look for a grey lock. EV certs generally have much more stringent requirements than "hey, give me a cert!".

[bigiain]

I'm pretty sure "People are trained to look for the green, not for the lock" is newer and not nearly as widely known advice as "look for the lock". And it's pretty obvious just looking around non-tech-related sites that even the "look for the lock" advice isn't all that well received - so many sites use images of padlocks on the page to imply "banking grade security!!!", surely not _all_ of them are incompetent - I have a strong suspicion that at least some of those people are doing it as part of high statistical significance validated A?B tested funnel optimisations...

[chinathrow]

Chrome has a green lock and green 'https' for this site, which hasn't an EV cert.

[nailer]

That's correct - only Chrome shows green locks for domain validated certs.

Firefox uses a grey lock for domain validated certs.

Edge uses a hollowed-out grey lock for domain validated certs.

[pakitan]

A valid certificate only allows you to have a secure connection without errors and warnings popping up all over. It does nothing to guarantee that the domain is "legit". You can already set up thecitibank.com and get an SSL certificate for it without any problem. What you can't do is get the EV (green bar) certificate where indeed you need to go through a human. But I'm pretty sure Let's Encrypt won't be giving away EV certificates.

[weavie]

Surely you would at least need access to a relevant email address on that domain? How would you bypass that?

[r0bbbo]

He would need to be in control of that domain entirely. thecitibank.com is just an address that looks legitimate and is purchasable.

[weavie]

Ok, I understand.

On a slight side note he may not necessarily need to control the domain entirely, just have access to a privileged email address [1]

However, now it seems you won't even need access to an email address. What would stop someone creating a cert for the real citibank.com and using it for a MITM attack? How many people actually check the green bar?

[1] http://arstechnica.com/security/2015/03/bogus-ssl-certificat...

[schoen]

In the live.fi example, it sounds like Microsoft may have failed to prevent a random user from registering [e-mail] as a personal account. Citibank probably won't allow a customer to get that e-mail address!

[weavie]

It was [e-mail] (http://www.tivi.fi/Kaikki_uutiset/2015-03-18/A-Finnish-man-c...)

[cpach]

”without any problem”

Are you sure about that?

[bigiain]

Yeah - there's many ssl vendors who've automated everything - so long as you can read email sent to [e-mail], they'll sign a csr for that domain's ssl cert.

[dtech]

Most certificate providers are already fully automated, the personal identity (not domain ownership) verification is the only human part.

[creshal]

Yes, you can.

You can also do the same at every existing CA that provides domain verified certificates. From personal experience neither StartSSL nor Comodo have a human in the look – until you want more than domain verification (e.g., "green bar" EV certificates).

[bigiain]

StartSSL at least have a human in the loop for your initial identity validation. They got in touch with me because I'd put a work address in instead of my home address, and they worked it out and sent me a very human-like email asking me to correct it.

[alfonsoperez]

I got also an email from a guy because my domain name had been registered that same day, telling me to wait, sure you can automate the check, but at least the email didn't look automated.

[superuser2]

We don't have humans in the loop for issuing certificate; this can and has been exploited for fun and profit, with fun attacks like getting a cert for "citibank.com\0.mydomain.com" which used to trick the C strcmp in most browser certificate checking routines. Moxie has an entertaining talk: https://www.youtube.com/watch?v=MFol6IMbZ7Y

Your problem would be getting people to "thecitibank.com." Chrome, Firefox, and GMail would all eventually figure out it was a phishing site and warn users about clicking through to it.

[stephenr]

As has been said, existing domain-validated (i.e. basic) certificates are automated anyway.

The type of certificate that banks etc use are EV - Extended Validation. This means the organisation details are verified as well, and as such the browser displays the verified organisation name in green in some cases, instead of any host/url at all).

[cbg0]

Actually it's automated in most places, simply requiring you to confirm a request via an e-mail address associated with the domain you're getting an SSL for (typically admin@ hostmaster@ webmaster@, though it varies between certificate providers).

[duskwuff]

Most of the reputable CAs have some practices in place to check for keywords related to big brands and auto-reject certificate requests. (So you can't get a certificate for "login-facebook.com" or whatnot, for instance.)

[chetanahuja]

"(So you can't get a certificate for "login-facebook.com" or whatnot, for instance.)"

You mean not from one of those "reputable" CAs. But really, why would I go to a "reputable" CA for my deceptive certificate if my intent is not so reputable?

[chetanahuja]

There's no requirement in the spec for using "reputable" CA's for certificates.

[johnnydoebk]

Could you provide a few examples of reputable and not so reputable CAs?

[rjaco31]

Just browse the truststore of your browser, you'd be surprised.

[rdancer]

No, they don't. What would be the point, anyway?

[duskwuff]

Er, from personal experience I can say that at least some well-known CAs absolutely do review keywords appearing in SSL certificate requests. For a (really stupid and disappointing) example, see:

http://forums.comodo.com/ssl-certificate-b14.0/-t106480.0.ht...