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

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

Post reply on HN
Print view View original

281–290 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#281

Post by Liquid_Fire »

peterwwillis wrote: post #272
Liquid_Fire wrote: post #264

Earlier quoted context omitted.

How would you solve it without HTTPS?

By signing it. "Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this. One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser woul…

And what happens when the content changes? Cacheability is not always a good thing. Your solution is vulnerable to replay attacks. You could be seeing an outdated version of a resource without knowing it. This is only acceptable for truly static content, which is becoming increasingly rare on the web.

Re: ACME v2 and Wildcard Certificate Support is Live

#282

Post by snowwolf »

detaro wrote: post #280
snowwolf wrote: post #279

Earlier quoted context omitted.

I'm intrigued. What kind of app that you could host on heroku requires wildcard certificates? Bearing in mind that heroku can't really support wildcard subdomains for a single app. Each custom subdomain for an app needs to be added to the app. And then if you enable Automated Certificate Management for the app (which uses LetsEncrypt under the covers), they'll happily fetch a cert for each listed subdomain. And Herok…

> Bearing in mind that heroku can't really support wildcard subdomains for a single app. Why not?

Well I suppose they could, but they'd have to be very careful of someone else spinning up an app and adding your domain to it.

Re: ACME v2 and Wildcard Certificate Support is Live

#283

Post by peterwwillis »

Liquid_Fire wrote: post #281
peterwwillis wrote: post #272

Earlier quoted context omitted.

By signing it. "Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this. One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser woul…

And what happens when the content changes? Cacheability is not always a good thing. Your solution is vulnerable to replay attacks. You could be seeing an outdated version of a resource without knowing it. This is only acceptable for truly static content, which is becoming increasingly rare on the web.

This content should not change, or change very rarely. A bulk of the data on the web is media files and static resources. Until browsers started locking down 3rd party requests, handling these over HTTP was standard. Obviously it was a security problem, but it wouldn't have been with this alternate method.

However, it's not that hard to avoid replay after cache expires. HTTP sends the Date of the response along with Cache-Control instructions. If the headers are also signed they can also be verified by a client. If the client sees that the response has clearly expired, it can discard the document. As a more dirty hack it can also retry it with a new unique query string, or provide it as an HTTP header and token which must be returned in the response.

Re: ACME v2 and Wildcard Certificate Support is Live

#284

Post by peterwwillis »

snowwolf wrote: post #278
peterwwillis wrote: post #219

Earlier quoted context omitted.

Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, b…

How would you go about verifying the domain from who controls the "IP space"? A cloud provider/datacenter controls the IP space in the majority of cases. If someone owns your DNS, they can use almost any CA to get valid certs for your domain (apart from EV only ones). That's kind of how Domain Certs work. "A domain-validated certificate (DV) is an X.509 digital certificate typically used for Transport Layer Security…

> If this is something that worries you, then you should only trust sites that have Extended Validation certificates.

Every user of the web in the world would have to do this in order to avoid this vulnerability.

Re: ACME v2 and Wildcard Certificate Support is Live

#285

Post by [deleted] »

cbo100 wrote: post #229
peterwwillis wrote: post #219

Earlier quoted context omitted.

Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, b…

> What am I missing here? If I "own your DNS" wouldn't I just change them all to an IP space I control anyway? (If that was a requirement). Unless I'm missing something, requiring "owning the IP space" seems to be an impossible requirement to fulfil. I'm on a virtual host in Azure/AWS/Linode I have no way of proving I own the IP (because I don't).

[deleted]

Re: ACME v2 and Wildcard Certificate Support is Live

#286

Post by peterwwillis »

schoen wrote: post #231
peterwwillis wrote: post #219

Earlier quoted context omitted.

Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, b…

I'm not quite sure how to answer this. DNS is used as ground truth for an enormous amount of certificate issuance by a broad range of CAs. This has been true for many years. Let's Encrypt didn't invent domain validation or the notion of relying on DNS as a basis for issuing DV certificates.

Honestly, it just hadn't occurred to me at all that DNS was the only thing stopping a blackhat from generating valid certs and siphoning or modifying traffic without anyone's knowledge. And users literally can't stop this other than to only accept EV certs, breaking most of the web. This is pretty nutty.

At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed?

Re: ACME v2 and Wildcard Certificate Support is Live

#287

Post by snowwolf »

peterwwillis wrote: post #284
snowwolf wrote: post #278

Earlier quoted context omitted.

How would you go about verifying the domain from who controls the "IP space"? A cloud provider/datacenter controls the IP space in the majority of cases. If someone owns your DNS, they can use almost any CA to get valid certs for your domain (apart from EV only ones). That's kind of how Domain Certs work. "A domain-validated certificate (DV) is an X.509 digital certificate typically used for Transport Layer Security…

> If this is something that worries you, then you should only trust sites that have Extended Validation certificates. Every user of the web in the world would have to do this in order to avoid this vulnerability.

Exactly. Domain verified certificates guarantee one thing and one thing only. The data transmitted is encrypted and cannot be tampered with. That's it. They do not guarantee you are communicating with who you think you are.

But to be honest if your DNS service is compromised, you have bigger problems.

Re: ACME v2 and Wildcard Certificate Support is Live

#288

Post by aplorbust »

icebraining wrote: post #247
aplorbust wrote: post #227

Earlier quoted context omitted.

"It's their privacy being deprived." I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow. Will these "advances" benefit users more than they benefit the companies serving ads, collecting user data and "overseeing the www" generally? Is there a trade-off? To users , will protecting tr…

I wonder if anyone will be surprised when they learn how HTTPS and HTTP/2 will be used to push more advertising to users and exfiltrate more user data from them than HTTP would ever allow. We're talking only by HTTPS. Adding HTTP/2 is just mudding the conversation. Care to give any argument on how does adding a TLS layer over the exact same protocol (HTTP/1.1) will be used to do that?

/I wonder/s/HTTPS/TLS/

Re: ACME v2 and Wildcard Certificate Support is Live

#289

Post by snowwolf »

peterwwillis wrote: post #286
schoen wrote: post #231

Earlier quoted context omitted.

I'm not quite sure how to answer this. DNS is used as ground truth for an enormous amount of certificate issuance by a broad range of CAs. This has been true for many years. Let's Encrypt didn't invent domain validation or the notion of relying on DNS as a basis for issuing DV certificates.

Honestly, it just hadn't occurred to me at all that DNS was the only thing stopping a blackhat from generating valid certs and siphoning or modifying traffic without anyone's knowledge. And users literally can't stop this other than to only accept EV certs, breaking most of the web. This is pretty nutty. At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being d…

How do you add that public key to the WHOIS register - Via your domain registrar (and it would have to be updateable/changeable outside of renewal cycles). Who is your DNS provider 90% of the time? Your domain registrar...

Re: ACME v2 and Wildcard Certificate Support is Live

#290

Post by niij »

vbezhenar wrote: post #269
niij wrote: post #184

Earlier quoted context omitted.

>wosign Are you name dropping wosign just to be obtuse? They were untrusted because they were untrustworthy, not because Google just doesn't like them. https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...

I don't trust any US company, so it's not any more untrustworthy for me than DigiCert, for example. I'm dropping its name because they were offering free 3-year certificates and it was the best TLS experience I've ever had.

There's a lot of countries I don't trust to keep sensitive data in. But my point is that Wosign was provably untrustworthy, rather than speculation on government interference in other CAs. I saw from your Github that you live in Kazakhstan, I would remind you the government is less than trustworthy as well[0] in regards to digital privacy.

[0]: http://www.slate.com/blogs/future_tense/2015/12/14/kazakhsta...

Post reply on HN