Description
Describe the bug
While the TCP listener (DesktopNetworkListener) is processing an SSL handshake, no further connections are accepted.
We are seeing situations in the wild where this SSL handshake is taking a long time, due to protocol mismatch, broken environments or buggy network software meddling with our bytes in transit.
More specifically, the method AuthenticateAsServer can hang for a long time.
See also dotnet/runtime#914, it looks like we're not the only ones running into this.
The good news is that we have 1 minute timeout (default, configurable via DefaultTlsAcceptor) that eventually makes us recover from the situation, but the bad news remains that we don't accept any extra TCP connections while this SSL handshake is frozen.
Today most of this is bugs or faulty setups, but I also imagine a bad actor with malevolent intentions that wants to screw up a DICOM listener somewhere that uses Fellow Oak DICOM. You could DDOS every Fellow Oak DICOM listener if you know how and are able to reach it.
To Reproduce
This is the hard part. I have some Wireshark captures that I still need to analyze, but I can reproduce the issue by manually sending the initial bytes of a TLS 1.2 handshake. Our server keeps waiting for more bytes to arrive (but they never do, in my little test), and I confirmed that spinning up a DicomClient then doesn't work until the bad handshake times out.
Expected behavior
I believe the SSL handshake should be offloaded to a background thread and should not block the main loop that accepts incoming TCP connections. Not only would this be a performance gain in the case of multiple connections, it would also solve this "bug".
Screenshots or test DICOM files
I'll write a unit test, this stuff is hard to reproduce.
Environment
Fellow Oak DICOM version: Latest
OS: Irrelevant
Platform: Irrelevant