Most active commenters
  • superkuh(3)
  • packetlost(3)

←back to thread

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

(httptoolkit.com)
596 points pimterry | 18 comments | 25 Jul 23 14:10 UTC | HN request time: 0.415s | source | bottom
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 #
1. 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 #
2. packetlost ◴[25 Jul 23 14:26 UTC] No.36862723[source]▶
Kinda surprised there isn't a few CAs that set up Let's Encrypt-like automated infrastructure that charge a small subscription fee for certificates. I'd pay $1-$3/m or so for preventing a mono-culture + big attack surface, but don't really want to give up the convenience of Let's Encrypt.

I know there's a big barrier to entry for being a CA (as there should be), but it shouldn't be impossible.

replies(2): >>36862744 #>>36865061 #
3. 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 #
4. Avamander ◴[25 Jul 23 14:27 UTC] No.36862744[source]▶
> Kinda surprised there isn't a few CAs that set up Let's Encrypt-like automated infrastructure that charge a small subscription fee for certificates.

There are other ACME-compatible CA's.

replies(1): >>36862805 #
5. packetlost ◴[25 Jul 23 14:31 UTC] No.36862805{3}[source]▶
Oh? Examples?
replies(1): >>36862858 #
6. capableweb ◴[25 Jul 23 14:34 UTC] No.36862858{4}[source]▶
https://zerossl.com/ is a popular alternative. https://www.buypass.com/ is another one I haven't personally tried.
replies(2): >>36863059 #>>36863145 #
7. 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 #
8. ehhthing ◴[25 Jul 23 14:44 UTC] No.36863023{3}[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.

9. snowwrestler ◴[25 Jul 23 14:45 UTC] No.36863036{3}[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.

10. ehhthing ◴[25 Jul 23 14:47 UTC] No.36863059{5}[source]▶
Also Google Trust Services has free certificates although you need a Google Cloud project for it.
replies(1): >>36863087 #
11. capableweb ◴[25 Jul 23 14:48 UTC] No.36863087{6}[source]▶
Not sure Google is a great alternative if you want to prevent further centralization of CAs :)
12. foul ◴[25 Jul 23 14:49 UTC] No.36863105{3}[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

13. water9 ◴[25 Jul 23 14:50 UTC] No.36863117[source]▶
"There are many different TLS certificate providers from different CA roots." - Yes but there are only a handful of browsers and they preselect the default CA providers. The average user is not going to be able to configure custom CAs and will effectively be denied service should those pre-selected CAs go rogue.
14. cyberax ◴[25 Jul 23 14:51 UTC] No.36863143[source]▶
Why? Just skip the CA verification when you use HTTP/3. Done.

While this is less secure than a verified certificate, it still avoids plaintext on the wire and requires an active MITM to eavesdrop.

15. packetlost ◴[25 Jul 23 14:52 UTC] No.36863145{5}[source]▶
Oh cool, I couldn't find those on Google. I'll check them out
16. detourdog ◴[25 Jul 23 15:09 UTC] No.36863452[source]▶
I think the whole changing identity all the time is the exact opposite of a human system. The type of system only a computer could love.

This seems like a such a wrong headed approach. LetsEncrypt favors constantly changing magic handshakes over long term good social behavior.

Imagine a network where machines that misbehaved were ostracised instead of being able to register certificates frequently.

I see the promise in the Fediverse as it's ability to develop reputations.

17. tehbeard ◴[25 Jul 23 15:30 UTC] No.36863765{3}[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.

18. seabass-labrax ◴[25 Jul 23 16:35 UTC] No.36865061[source]▶
I think that Let's Encrypt gets a lot of undeserved criticism for being the only major ACME-compatible CA. Yes, it's not so good to have monopolies on authenticity, but Let's Encrypt was founded by Mozilla, the EFF and the University of Michigan and was endorsed by the FSF.

That's a pretty good set of organisations when considering the general status of the internet, and a set that doesn't overlap with the major players in consumer technology (Apple, Microsoft and Google).