Live data from Hacker News

WebPKI and You

blog.brycekerley.net

1–10 of 24 posts

Re: WebPKI and You

#4
The short lived certificates started making a lot more sense to me when I discovered I could get Let's Encrypt to issue IP address certs. Clearly, in this context of use we need our certificates to die quickly.

You can now make any web server operate with a publicly valid TLS certificate without paying any money, registering a domain, configuring DNS or disclosing any personally identifiable information. It can be entirely automatic and zero configuration. The only additional service required is something like a STUN server so the public IP can be discovered and updated over time.

Re: WebPKI and You

#5
post #4

The short lived certificates started making a lot more sense to me when I discovered I could get Let's Encrypt to issue IP address certs. Clearly, in this context of use we need our certificates to die quickly. You can now make any web server operate with a publicly valid TLS certificate without paying any money, registering a domain, configuring DNS or disclosing any personally identifiable information. It can be en…

I am reading your comment and find the proposition interesting, but I can't quite understand the part about the STUN server - doesn't that "just" help me find my own public IP address ? Do you mean that I could then give out this address to others (instead of them having to do a DNS lookup) so they can connect to the webserver ?

Re: WebPKI and You

#6
It's worth noting that while splitting the PKI hierarchies is a good thing, the CABF does provide rules S/MIME (email signing) and Code Signing. Also, "WebPKI" never actually appears in the BR documents from what I can see, nor do they require the use of HTTP (hence why you can use these for SMTP).

Re: WebPKI and You

#7
post #5
post #4

The short lived certificates started making a lot more sense to me when I discovered I could get Let's Encrypt to issue IP address certs. Clearly, in this context of use we need our certificates to die quickly. You can now make any web server operate with a publicly valid TLS certificate without paying any money, registering a domain, configuring DNS or disclosing any personally identifiable information. It can be en…

I am reading your comment and find the proposition interesting, but I can't quite understand the part about the STUN server - doesn't that "just" help me find my own public IP address ? Do you mean that I could then give out this address to others (instead of them having to do a DNS lookup) so they can connect to the webserver ?

> I am reading your comment and find the proposition interesting, but I can't quite understand the part about the STUN server - doesn't that "just" help me find my own public IP address ?

He is hosting his domain on a machine behind a reverse proxy over which he has no control (common enough); in this case the server will not know its own public IP as all resolves to (for example) `www.mydomain.com` will return the address of the proxy. To get the public IP he uses a STUN (or similar) public-facing service.

Not quite sure why he needs the public IP, though: from what I remember, the certs include the domain, not the IP.

Re: WebPKI and You

#8
post #5
post #4

The short lived certificates started making a lot more sense to me when I discovered I could get Let's Encrypt to issue IP address certs. Clearly, in this context of use we need our certificates to die quickly. You can now make any web server operate with a publicly valid TLS certificate without paying any money, registering a domain, configuring DNS or disclosing any personally identifiable information. It can be en…

I am reading your comment and find the proposition interesting, but I can't quite understand the part about the STUN server - doesn't that "just" help me find my own public IP address ? Do you mean that I could then give out this address to others (instead of them having to do a DNS lookup) so they can connect to the webserver ?

Yes the point is to simply discover the public ip you present as on the internet. It's not a particularly hard problem to solve, but you often can't know your public interface just from inside the machine. Being behind a NAT with TCP 80/443 forwarded to the actual web server is an example.

Re: WebPKI and You

#9
post #5

Earlier quoted context omitted.

I am reading your comment and find the proposition interesting, but I can't quite understand the part about the STUN server - doesn't that "just" help me find my own public IP address ? Do you mean that I could then give out this address to others (instead of them having to do a DNS lookup) so they can connect to the webserver ?

> I am reading your comment and find the proposition interesting, but I can't quite understand the part about the STUN server - doesn't that "just" help me find my own public IP address ? He is hosting his domain on a machine behind a reverse proxy over which he has no control (common enough); in this case the server will not know its own public IP as all resolves to (for example) `www.mydomain.com` will return the a…

You can issue a TLS certificate with a SAN that is a literal IPv4 address. You do not need a domain to serve TLS to clients. It definitely helps with the UX, but it's not mandatory for the browsers and other web tech to function.

Re: WebPKI and You

#10
There's a huge suggestion in here which would make PKI vastly more respectable: Disallowing root programs (browser operators) from also being CAs. I loudly suggested at the time Google Trust Services should be rejected but the Mozilla rep loudly defended approving a CA from a root program from a company that happens to pay their entire salary.

PKI as it stands is only a few steps from Google just deciding everyone must have a short-lived certificate from Google to be on the web.

Post reply on HN