-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to check TLS contexts, servernames, altnames #24095
Comments
re:
It is the inverse of However... I'm confused by your later discussion of the If what you need is to know the cert that was actually selected by OpenSSL as matching the negotiated cipher suite, then that would be a different kind of API, not the inverse of |
Re default Re The goal
Example
GoodIn firefox the TLS session is reused for the transition between BadIf using a malicious client we don't want it to be allowed that the client establishes a connection at Hence detecting which Subject/Altnames are inclusive/exclusive is desirable. Current WorkaroundWithin |
People do this? The SAN is supposed to be an alternative to the subject that allows specifying normal internet names (emails, dns, etc), since the actual subject is a path in a non-existent OSI global directory tree, and didn't allow DNS names... except the |
Many sites have done this over the years (ostensibly due to the expense of wildcards in comparison to listing multiple domains on a single cert). In particular virtual hosting sites (similar to but not necessarily including heroku and wix). I've personally witnessed it. Let's Encrypt has rate limits, so they encourage putting up to 100 names on a single certificate: https://letsencrypt.org/docs/rate-limits/ However, perhaps the example I gave was too extreme. Keep everything else the same in what I said before, but change it to this:
The exact same problem problem emerges: If Firefox reuses the session established with www.example.com when connecting to api.example.com, and they are both listed on the cert, I'd like to have a node-native way to distinguish that from Domain Fronting (they are not both listed on the cert). |
Oooh! That looks very nice. It's not clear to me from the example the altnames are represented there, but it looks like they might be and I've got a way to figure that it if not. While you're in that code... could you possibly also expose the function that parses the PEM as well? Thanks a bunch! Do you have a "buy me a coffee" button somewhere? |
I'd like to, but that would take more thought as to API. It might even require a new X.509 object type. https://www.npmjs.com/package/asn1.js may be your best bet for that ATM. |
SANs are supported, though as @bnoordhuis points out, there are no docs for the object fields. Sorry. Line 1607 in 8884a98
|
Add an API to get the local certificate chosen during TLS handshake from the SSL context. Fix: nodejs#24095
Add an API to get the local certificate chosen during TLS handshake from the SSL context. Fix: nodejs#24095 PR-URL: nodejs#24261 Fixes: nodejs#24095 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Again, thank you. |
Add an API to get the local certificate chosen during TLS handshake from the SSL context. Fix: nodejs#24095 PR-URL: nodejs#24261 Fixes: nodejs#24095 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
We have
server.addContext(hostname, context)
, but we don't have aserver.getContext(hostname)
.Why?
Now, that might seem rather silly, but let me explain why it would be important to have this:
There's a type of spoofing known as Domain Fronting where the attacker creates a TLS session with one SNI, but once connected they send a different HTTP Host header (more info on a bug I created including this at #22389).
There's an RFC that specifically prohibits this behavior, which many cloud platforms follow, but node does not currently follow.
However, there's a catch. Another RFC in relation to HTTP/2 contradicts the former and suggests reusing the same TLS connection for a different servername when the certificate in the session includes the new servername (more info at https://www.ietf.org/mail-archive/web/httpbisa/current/msg28781.html).
Current versions of Firefox actually follow the second spec presently.
I want to block domain fronting, but not to the exclusion of allowing Firefox to reuse tls sessions.
Currently I'm checking that the
Host
header matches thetlsSocket.servername
(when it exists), but in order to support Firefox I need to know thealtnames
(SAN) as well, but I haven't been able to figure out a way to get that information from the socket.I'm looking for another workaround, but this seems like something that node could reasonably expose in a future version to make such checks easier.
The text was updated successfully, but these errors were encountered: