Hi Eduard,
First thing to check is that your client is offering a TLS version that
the server supports. By default, PskTlsClient offers TLSv1.2
(ClientVersion property) and will work back to TLSv1.0 (MinimumVersion
property). It's unlikely to be the issue unless the server only supports
SSLv3.
Second thing to check is that your client is offering at least one
cipher suite that the server understands. This is controlled by
overriding GetCipherSuites (in WoprClient). PskTlsClient defaults:
public override int[] GetCipherSuites()
{
return new int[]
{
CipherSuite.TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256,
CipherSuite.TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA,
CipherSuite.TLS_DHE_PSK_WITH_AES_128_CBC_SHA256,
CipherSuite.TLS_DHE_PSK_WITH_AES_128_CBC_SHA
};
}
Preferably find out exactly what cipher suites the server supports, or
if you have to guess, try including TLS_PSK_WITH_AES_128_CBC_SHA and
TLS_RSA_PSK_WITH_AES_128_CBC_SHA in the list.
Presumably the IOException is not particularly helpful. You can often
get much better information by overriding (in WoprClient again) the
NotifyAlertRaised and NotifyAlertReceived methods. The first will
usually give you the exact location where the client failed, the second
at least lets you know that it was the server that aborted, and with
what alert, but you would then need to consult server-side logs or
debugger to understand the exact reason (most alerts don't identify a
specific issue).
Perhaps report back after you've tried the above.
I noticed also in Program.cs that you are using ASCII.GetBytes in your
GetPsk() method, which is probably wrong and ought to be decoding it as
a hex string (e.g. use Org.BouncyCastle.Utilities.Encoders.Hex.Decode).
Regards,
Pete Dettman
P.S. Actually just looked at your wireshark log; the left pane shows the
server selecting TLSv1.2 and TLS_PSK_WITH_AES_256_CBC_SHA, if I'm
reading it right.
On 18/02/2017 10:55 PM, Eduard Bloch wrote:
> Hello BCL developers,
>
> I have to issues to report. First, the search engine of your mailing
> list archive is throwing a 500 HTTP error.
>
> Second, I was developing something where I stumbled a potentially issue
> in BCL (C# version). The setup is like this:
> - remote server written in C++ (Boost::ASIO and OpenSSL)
> - PC client written in C#
> - using pre-shared keys
>
> Using PSK is quite new to me, so I first prepared a demo client/server
> (hacked on a simple client&server demo from a German ASIO/OpenSSL
> tutorial, links see below). This works quite well, I see server sending
> the hint, client receiving it and sending identity and psk and
> everything works smoothly.
>
> BCL client, however, does not work at all. I subsclassed PskTlsClient
> and PskTlsClient (mostly following the unit test example, feeding it
> with the same data as OpenSSL version; link below). But when the TCP
> communication is established the handshake fails. Instead, there is a
> generated IOException (details see below).
>
> Checking Wireshark log confirms that the handshare is aborted right in
> the beginning (the WORP / IAMLEGEND containing parts are never
> exchanged):
> https://www.unix-ag.uni-kl.de/~bloch/.wearetheborg/pskbug/openssl_vs_BCL_client.png
>
> Does anyone have an idea on what's going wrong? I might be overlooking
> something (enabling specific TLS version?) but I cannot figure out what.
>
>
> https://www.heise.de/developer/artikel/SSL-TLS-Netzwerkprogrammierung-mit-Boost-Asio-Teil-3-Client-Programmierung-und-Fehlerbehandlung-3161904.html
> https://www.heise.de/developer/downloads/06/1/7/8/5/1/9/9/wopr-3.00.tar.bz2
> https://www.unix-ag.uni-kl.de/~bloch/.wearetheborg/pskbug/WOPR_pskmod.diff
> https://www.unix-ag.uni-kl.de/~bloch/.wearetheborg/pskbug/Program.cs
>
> Best regards,
> Eduard.
>
