Skip to content
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

Certificate selection for servers is missing #310

Open
TechnikEmpire opened this issue Aug 31, 2021 · 4 comments · May be fixed by #456
Open

Certificate selection for servers is missing #310

TechnikEmpire opened this issue Aug 31, 2021 · 4 comments · May be fixed by #456

Comments

@TechnikEmpire
Copy link

TechnikEmpire commented Aug 31, 2021

SSL_CTX_set_tlsext_servername_callback is not implemented.

To write a modern TLS enabled server, this callback is required. Why? Because a modern server should be capable of being initialized with a default SSL_CTX that implements the SNI callback and, if executed (when SNI is present in the client hello), you should be able to fetch or generate a SSL_CTX specifically for that host (fetched with SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name)) and then also dynamically change the context in use for that connected client SSL object via SSL_set_SSL_CTX() before returning from the callback.

Without this, you can only write servers like its 2002 (SNI was introduced in 2003).

I'll see if I can do a PR but it may not come soon. It should be trivial to implement for someone who already knows their way around this library.

@Dragollla
Copy link

It is possible to use SNIHandler and insert NIOSSLServerHandler with required context (certificate)

@Lukasa
Copy link
Contributor

Lukasa commented Oct 13, 2021

It is indeed. However, we should have a plan to supplement this, as the SNIHandler is not capable of handling an encrypted ClientHello, and doesn’t work with QUIC.

@TechnikEmpire
Copy link
Author

TechnikEmpire commented Oct 13, 2021

Just a quick FYI, the working group responsible has paused ECH draft after a heated argument with me where I explained to some of the members how stupid it was on openssl ticket. Whether it is moving forward will be discussed next month at their meeting.

If anyone cares, the stupidity of it is that any executable code will be able to establish fully opaque encrypted connections from start to finish with even the host device admin / ring 0 not being capable of knowing what is in it.

DoH to resolve endpoint -> opaque
ECH -> opaque
DoH to do dns loop jumping to complete ECH -> opaque

There's a billion dollar blackhat industry drooling over themselves waiting for a free license to do whatever they'd like over your home and corporate network. Anyway just fyi, it's not certain whether ECH will progress.

@TechnikEmpire
Copy link
Author

TechnikEmpire commented Oct 13, 2021

To be clear, its not stupidity if your goal is to transfer privacy to megacorps who then will have an absolute monopoly on the cybersec market, which the rep from akamai admitted was a factor in their motivations. Comments were deleted after but I slapped them up on archive.org first. Anyway.

@AndrewBarba AndrewBarba linked a pull request Jan 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants