1.0.164 kills SNI

[TechnikEmpire]

I'm using your excellent library in my project CitadelCore, specifically in this class, and updating to the latest release makes TLS stop functioning in my proxy. Assuming it's not my fault, my first guess from experience would be buffer offsets (that fake the peek operation) getting out of wack.

Assuming it is my fault, it could be how I was invoking the peek operation. Since you changed the collection to a dictionary and it returns a standard key value pair, I had to check for success by comparing my server_name query against default(KeyValuePair<string, XClassNameIForget>). Anyway I don't think it was this, because in my logging I was still succeeding at extracting the host name.

If I had more time right now, I'd dig into it but I'm swamped with work. Rolling back to 1.0.81 gets me back to being functional.

[honfika]

I dint understand this issue, since there is no method/property in StreamExtended package which returns KeyValuePair.

Maybe you mean this:
public Dictionary<string, SslExtension> Extensions { get; set; }

But it seems to work.

You can get the server name with this code:

            if (clientHelloInfo.Extensions != null &&
                clientHelloInfo.Extensions.TryGetValue("server_name", out var serverNameExtension))
            {
                return serverNameExtension.Data;
            }

[TechnikEmpire]

Linq. Anyway, its broken.

[TechnikEmpire]

Not sure how else to explain it without fixing the entire issue myself. It's straight up busted. I didn't realize that giving the wrong object type name would completely mask the suggestion that the buffer offsets are ruined. It's impossible to complete a TLS handshake with the latest version. The entire handshake fails and sits there and hangs till it times out, like one party is waiting on the other to send data it never sends.

[honfika]

But there are no problems with the offsets. You also wrote that it was still succeeding at extracting the host name. So parsing the clientHello is ok, right?
And you never receive the server hello? Maybe you are not flushing the stream. We also use this package in a smiilat proxy project that you have (https://github.com/justcoding121/Titanium-Web-Proxy) and it works.

[TechnikEmpire]

@honfika You know you may be right, I'll have a look when I have time and make sure I didn't screw something up. All I know is that it works perfectly in my engine at the previous stable release, and my engine (HTTPS anyway) dies and doesn't functional at all with the latest release. After realizing this, I simply rolled back and filed here without doing any sort of additional investigation.

Very neat project by the way, it gets a star from me. My project is a little different, as it's designed to function primarily as a transparent intercepting proxy for the purpose of content filtering. FYI you guys should look at integrating kestrel. HTTP2 support is on the way, among other things. In upcoming 2.1, it's pure managed again (no libuv), etc etc. I started out as a C++ transparent proxy, having to code everything HTTP related myself (mostly) and I can't tell you how nice it was to outsource 90% of the maintenance burden to Microsoft for free. 😄

Anyway I'll do some real investigation once I have time. Feel free to close this out if you're confident that I'm wrong and thanks for your time.

[honfika]

Can you reproduce this issue every time, or only happens sometimes?