5 ms·
Can anyone make sense of what they're trying to tell there? They found some issue ("irregularities") and made 2 changes, but the changes are merely restricting
by hannob 5y ago
Can anyone make sense of what they're trying to tell there?
They found some issue ("irregularities") and made 2 changes, but the changes are merely restricting the TLS version to 1.2 and deprecating an old OID identifier. While TLS < 1.2 certainly is not ideal, I don't see how this would impact the ACME validation, and the old OID should be irrelevant as well.
(I have been somewhat concerned about the security properties of the acme/alpn validation for unrelated other reasons, but haven't been able to pin that down to a specific threat - notably the RFC implies that the security is improved due to strict ALPN validation, which in practice usually does not happen.)
Update: RFC 8737 (the ALPN validation method) says "ACME servers that implement "acme-tls/1" MUST only negotiate TLS 1.2". So maybe this is "just" a policy issue?
- walrus01 5y agoThe population of browsers and things that don't understand TLS1.2 is miniscule now, so there should be no impact in disabling tls1.1 and below anywhere possible.
- YPPH 5y agoBrowsers aren't to the point here, it is referring to servers seeking to verify control of a domain, by conducting a “acme-tls/1” handshake initiated by the Let's Encrypt issuance server. If such a server only supports TLS 1.1, then TLS-APLN-01 validation will fail after this change is implemented.
- walrus01 5y agoNobody should be running tls1.1 only (and incapable of opportunistically negotiating for 1.2 or 1.3 instead) on their public facing httpd in 2022, I disabled everything below 1.2 on some rather high traffic websites several years ago with zero impact.
- perlgeek 5y agoIt seems the reasoning here is: the TLS handshake might have used an insecure TLS version, and so they cannot be sure that the handshake worked the way they thought, and so the certificates could have been issued to the wrong party. I don't have a deep understanding of the TLS-ALPN-01 validation nor of the vulnerabilities they might be concerned about, but that would be the only reason for revoking certificates (unless it's more of a political statement, "we revoke certs when we screwed up!").
- tialaramex 5y agoI have absolutely no insider knowledge. However, we have seen lots of incidents where the actual problem is that we'd relied upon something that seems like it should be true and actually isn't. So what about a situation where an HTTPS server accepts tls-alpn-01 validation attempts but actually it has no idea what tls-alpn-01 validation even is ? Maybe it takes some (or all?) TLS extensions and just pretends to accept them. On a bulk host I think you could abuse that to get "validated" despite having only a very tangential relationship (sharing an IP address) to the validated name, similar to the problem with previous TLS based validation methods. The draft RFC for tls-alpn-01 says TLS 1.2 is mandatory, so, while that might be unrelated, it also might be that there's a bunch of servers out there which get this wrong but don't speak TLS 1.2 and the expectation is that nobody will upgrade them to speak TLS 1.2 but still get this wrong (or maybe for other reasons their misbehaviour means they'll catch fire in TLS 1.2)
- phicoh 5y agoJust a random guess. The security of TLS-ALPN-01 relies on TLS implementations rejecting a connection if an unknown ALPN is present. It is possible that TLS 1.1 and earlier do not require this behavior leading to exactly the SNI confusion that this mechanism was meant to prevent.
- hannob 5y ago> The security of TLS-ALPN-01 relies on TLS implementations rejecting a connection if an unknown ALPN is present. I hope it does not, because the majority of servers don't reject unknown ALPNs. (See: ALPACA attack)
- phicoh 5y agoRFC 8737, Section 5: "The second assumption is that a server will not violate [RFC7301] by blindly agreeing to use the "acme-tls/1" protocol without actually understanding it." RFC 7301, Section 3,2: "The server SHALL NOT respond with a selected protocol and subsequently use a different protocol for application data exchange."
- jaas 5y agoHead of Let’s Encrypt here. This is a compliance issue, there is no security or validation integrity risk.
- cryptofistMonk 5y agoDamn, unfortunate that you will revoke all these certificates if there is truly no security risk. This is likely going to break a lot of our users, or require manual intervention within the next 42 hours.
- Kesseki 5y agoIt is unfortunate. It's required: https://github.com/cabforum/servercert/blob/main/docs/BR.md#4911-reasons-for-revoking-a-subscriber-certificate https://github.com/cabforum/servercert/blob/main/docs/BR.md#...