This is both a practical and theoretical question. Practical: openssl s_server doesn't do SNI, but maybe a trivial proxy could. Theoretical: keys for different sites behind same public IP should not be accessible to the process (or even host) accepting connections.
-
-
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
yes? the client sends the SNI as part of the handshake, the server it's connecting to can then present the right cert?
-
I mean: is there state at this point that would be nontrivial to hand off to the backend? Or can the multiplexing proxy just wait til it's seen the SNI name, then forward everything seen so far and all future traffic to the right backend?
-
having not written a load balancer, i'm not sure how trivial that is. It has to wait till it's seen the SNI to decide where to send it? I think cloudflare has done work on this kinda thing?
-
Ok, so a big yes and it's already done. Heavier deps than I'd like but I might just go with it or copy out the concept to a minimal subset.
End of conversation
New conversation -
-
-
Yes, until we get encrypted SNI
-
Even then it should be possible, but with a nontrivial handoff. The backend would need to be able to confirm the shared secret negotiated by the proxy for SNI was not MITM'd.
End of conversation
New conversation -
-
-
From what I understand, SNI is sent in the client hello; that is, it gets sent before the server is supposed to respond to anything.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.