←back to thread

Apple already shipped attestation on the web, and we barely noticed

(httptoolkit.com)
596 points pimterry | 5 comments | 25 Jul 23 14:10 UTC | HN request time: 0.419s | source
Show context
superkuh ◴[25 Jul 23 14:15 UTC] No.36862573[source]▶
Google/Microsoft/Apple essentially did this with HTTP/3 too. None of their shipped browsers are able to connect to a non-"CA TLS" HTTP/3 endpoint. To host a HTTP/3 website visitable by a random normal person you have to get continued approval (every 3 months min) from a third party CA corporation for your website.
replies(2): >>36862591 #>>36863130 #
2OEH8eoCRo0 ◴[25 Jul 23 14:17 UTC] No.36862591[source]▶
What do you mean approval? You'd need a cert from an entity like Let's Encrypt?
replies(1): >>36862610 #
superkuh ◴[25 Jul 23 14:18 UTC] No.36862610[source]▶
Yep. LetsEncrypt is great but everyone centralizing in them is not so great. Normal browsers having the ability to connect to a bare HTTP endpoint in HTTP/3 would solve any problems that might arise from this centralization. It's a straightforwards and easy thing to fix for the HTTP/3 lib devs and mega-corp browsers using those libs. But no one cares about it.
replies(4): >>36862723 #>>36862727 #>>36863143 #>>36863452 #
cj ◴[25 Jul 23 14:26 UTC] No.36862727[source]▶
https://www.smashingmagazine.com/2021/08/http3-core-concepts...

> While TLS 1.3 can still run independently on top of TCP, QUIC instead sort of encapsulates TLS 1.3. Put differently, there is no way to use QUIC without TLS; QUIC (and, by extension, HTTP/3) is always fully encrypted.

Basically there is no HTTP/3 without a TLS certificate.

I'm not sure what "problems that might arise from centralization" might be. There are many different TLS certificate providers from different CA roots.

Is your gripe that you don't like TLS? Judging by how long the migration from TLS 1.1 to 1.2 took, I assume we're at least 10-15 years away from a world where everything is encrypted by default without backwards compatibility (if we ever get there at all).

replies(2): >>36862859 #>>36863117 #
1. superkuh ◴[25 Jul 23 14:34 UTC] No.36862859[source]▶
>Is your gripe that you don't like TLS?

I'm flabberghasted that that's what you took away from my comments. I thought I was very clear. My issue is the lack of HTTP support in HTTP/3 implementations shipped by the mega-corps (CA HTTPS only). CA TLS is definitely the least worst solution we have and I am not against it. I am saying major browsers' HTTP/3 implementations lack of bare HTTP support in HTTP/3, combined with short TLS cert lifetimes these days, is effectively attestation and that's bad. "Basically there is no HTTP/3 without a TLS certificate." is bad.

It could be slightly mitigated by the mega-corp implementations of HTTP/3 they ship accepting non-CA root based self-signed certs with a scaremongering click-through. But that's also no longer an option. If no company running a CA will give you a cert you'll simply be unvisitable (on HTTP/3). It makes the web something only for commercially approved sites.

replies(4): >>36863023 #>>36863036 #>>36863105 #>>36863765 #
2. ehhthing ◴[25 Jul 23 14:44 UTC] No.36863023[source]▶
> If no company running a CA will give you a cert you'll simply be unvisitable (on HTTP/3).

This isn't technically correct. I believe on the security warning page you can type "thisisunsafe" (just blindly do it) and it'll let you through.

At the very least this works for bypassing HSTS.

3. snowwrestler ◴[25 Jul 23 14:45 UTC] No.36863036[source]▶
It’s the opposite of the attestation scheme under discussion, because it requires the server to satisfy attestation, while the client can be whoever. Whereas the Apple and Google schemes require the client to satisfy attestation.

I agree with you on the necessity of maintaining support for bare HTTP in the Web ecosystem. But I think you’re not likely to get as much support on this, simply because far fewer people run servers than clients.

I kind of doubt that clients will ever connect exclusively via HTTP/3. I think browsers keep bare HTTP support. Maybe at some point it may be hidden behind a client config flag.

4. foul ◴[25 Jul 23 14:49 UTC] No.36863105[source]▶
Security measures like Cloudflare anti-DDOS reverse proxy rely precisely on widespread TLS, can deny access to any client not performing sanctioned TLS handshake (like curl, scrapers, or even old browsers which by chance can do TLS 1.2).

https://github.com/lwthiker/curl-impersonate

5. tehbeard ◴[25 Jul 23 15:30 UTC] No.36863765[source]▶
So the gripe is TLS then, because that cert is less about attestation and more not wanting Verizon et al. to inject ads or snoop your data between customer and server.

Attestation is at best a transient side effect of proving your ownership/control of a domain name...

There's perhaps better ways for you to articulate this point I think you are trying to make of "closed club" of Certificate Authorities.

That said a basic google search demolishes that point with there being alternatives to LE.

Also bemoaning the 90 day period seems really weird.