Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Encrypt is Trusted

letsencrypt.org

Post reply on HN
Print view View original

311–318 of 318 posts

Re: Let's Encrypt is Trusted

#311

Post by bandrami »

Gregordinary wrote: post #213
bandrami wrote: post #187

Earlier quoted context omitted.

Probably because EV certs are a stupid idea. Do you really know the difference between Citi Bank and Citibank? No? Then EV hasn't saved you from being phished.

Well, you can't just order an EV cert for "Citi Bank" unless you have "Citi Bank" registered as a legal entity. Section 9.2.1 (Page 9): https://cabforum.org/wp-content/uploads/EV-V1_5_7.pdf In addition to using & verifying the legally registered name, it must be verified that there is a physical address for the business, if that address doesn't match the registered location, additional verification is required. There…

Obviously the Citi example was a joke, but most actual certificates I see are to "R L Media Enterprises" or whatever the D&B name of the business is, which is opaque to me anyways.

Re: Let's Encrypt is Trusted

#312

Post by NateDad »

bpicolo wrote: post #266
NateDad wrote: post #63

Earlier quoted context omitted.

> They provide docker packaging. So it's just as dep-free as Go. ...except needing docker and everything running it in a docker container entails over a simple CLI. Also, it looks like they say "for god's sake don't pip install": Please do not use python setup.py install or ``sudo pip install`. Those mode of operation might corrupt your operating system and is not supported by the Let’s Encrypt team! https://letsencr…

That doesn't say not to use pip install. It says not to do it as root. So yes, pip install away

Ahh, confusingly worded. I would expect it to say something like "if you use pip install, don't use sudo" not "don't use sudo pip install" ... the alternative to "don't use sudo pip install" is ... everything else in the world, so I sort of assumed it just meant, don't use pip in general.

Re: Let's Encrypt is Trusted

#313

Post by nnrocks »

ghshephard wrote: post #177
huskyr wrote: post #149

Earlier quoted context omitted.

> it took me just a couple of hours > to learn how the process is handled at StartSSL. Well, if something takes 'just a couple of hours' to learn i'll happily fork over some money to ease the pain. You can get certificates for $10/year nowadays.

"You can get certificates for $10/year nowadays." As a service to the community, could you name some places where you can do that?

https://www.cheapsslshop.com/comodo-positive-ssl

Re: Let's Encrypt is Trusted

#314

Post by bandrami »

mike_hearn wrote: post #249
bandrami wrote: post #187

Earlier quoted context omitted.

Probably because EV certs are a stupid idea. Do you really know the difference between Citi Bank and Citibank? No? Then EV hasn't saved you from being phished.

EV certs are expensive because they have people in the loop, and so getting a cert for an obviously misleading name should be much harder. You'd have to pass an eyeballed sanity check.

You have much greater faith in the CAs' probity and competence than I think is warranted.

Re: Let's Encrypt is Trusted

#315

Post by idibidiart »

vtlynch wrote: post #286
idibidiart wrote: post #107

Earlier quoted context omitted.

I personally argued with the W3C TAG against an HTTPS-only web for this reason. Tim Berners Lee, who heads the TAG, ceremonially speaking, argued against it, too, but on different ground. The browser vendor 'experts' on the TAG totally dismissed any and all argument against forcing everyone to use HTTPS. They were basically told by their employers (the big browser vendors and CDNs like Akamai) to make it happen. HTTP…

>Now anyone who wants to setup a website, for whatever reason, has to go thru some central authority Which 99% of people already do when the buy a domain name. There is NO evidence that using SSL restricts your freedom of speech. There is evidence to the contrary though, where SSL allowed people to speak freely without having their communications intercepted or monitored. Certificate Authorities only reject websites…

"HTTPS IS encrypted"

Oh wow. Really? You haven't done your homework then. So many ways to undermine the certificate authority model, including many famous cases, one involving the Iranian government gaining access to their citizen's "encrypted" traffic. HTTPs is about having traffic be open to powerful entities and closed off to the common criminal. It's a two tier model, not real security.

Re: Let's Encrypt is Trusted

#316

Post by alwillis »

okigan wrote: post #273
alwillis wrote: post #165

Earlier quoted context omitted.

This is why HTTP Public Key Pinning was created as a way to tell browsers to trust only a particular certificate, not just any certificate that was signed by a CA in the browser's trust store: https://news.ycombinator.com/item?id=10418144 .

Another follow up: from your link, looks like the server adds a header specifying which certificates are allowed. Would not MITM just remove that header?

From the RFC: https://tools.ietf.org/html/rfc7469

Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)

The UA will not be able to detect and thwart a MITM attacking the UA's first connection to the host. (However, the requirement that the MITM provide an X.509 certificate chain that can pass the UA's validation requirements, without error, mitigates this risk somewhat.) Worse, such a MITM can inject its own PKP header into the HTTP stream, and pin the UA to its own keys. To avoid post facto detection, the attacker would have to be in a position to intercept all future requests to the host from that UA.

Thus, key pinning as described in this document is not a perfect defense against MITM attackers capable of passing certificate chain validation procedures -- nothing short of pre-shared keys can be. However, it provides significant value by allowing host operators to limit the number of certification authorities that can vouch for the host's identity, and allows UAs to detect in-process MITM attacks after the initial communication.

Re: Let's Encrypt is Trusted

#317

Post by alwillis »

peterwwillis wrote: post #206
alwillis wrote: post #158

Earlier quoted context omitted.

Thanks to HTTP Public Key Pinning (HPKP), this is no longer a threat: HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rog…

You don't get to say there is no threat if almost every website today is vulnerable. First, this is optional software that almost every public server in the world is currently not using. It's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists. In addition to actually implementing it on your ser…

You don't get to say there is no threat if almost every website today is vulnerable.

I didn't mean that literally the threat has been eliminated due to HPKP; it's yet another tool that can be used.

First, this is optional software that almost every public server in the world is currently not using. It's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists.

HPKP isn't software--just additional HTTP headers that pretty much every web server can be configured to send.

In addition to actually implementing it on your server, every single user still has to make a secure initial connection over a trusted network on every device they'll ever use to get to that site.

True; it's even described in the RFC: https://tools.ietf.org/html/rfc7469

Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)

Re: Let's Encrypt is Trusted

#318

Post by dSnapApjw »

I like that statement "community trust"...much the same I have come to trust most of the wisdoms on this site. I for one-learn, and greater, I learn from each of you the value of clarity. So trust as David Abshire says, "Is the coin of the realm, the glue, the oil, (alternative energy-) ingredient."txs, dSnapAp. SFCA.
Post reply on HN