Jørn Åne de Jong

This will prevent users from connecting to unsecured WeeChat instances, only WeeChat with TLS will be supported then. This is because a webbrowser will refuse to connect to an unsecure...

I think the error message the user gets when connecting to a hostname is useful. I also think that refusing to connect is too strict, and I think it's not...

If browser vendors reject insecure websockets, that does impact Glowing Bear users, but all Glowing Bear can do is warn users about this. Even when insecure websockets are blocked, there...

Thanks! Olav already explained this to me, but it's good that this is now also documented for others having the same problem.

The HTTP/2.0 spec allows to re-use a TCP session for different hostnames when the IP is the same and the certificate is valid for both hostnames. So this is not...

#268 made me wonder, if we modify the buffer to drop the http2 flag, that would probably fix the problem of connection reuse, since connection reuse is only allowed in...

As I understood it, ESNI must be enabled by the server admin by publishing some DNS records. As long as an sniproxy instance doesn't publish these DNS records, nothing changes....

> Sniproxy seems to be unable to obtain the private key to unlock the encrypted information of ESNI. It depends on the use-case. I use sniproxy for routing requests to...

I found a solution for those who want to use sniproxy for outbound routing as well. If you combine it with a DNS server that blocks ESNI-lookups (TXT _esni.example.com), the...

> I think the solution works only when the user is using your DNS server. This is correct for outgoing connections, but in order to use sniproxy for outgoing connections,...