Hallo Peter,
* Peter Dettman [Sun, Feb 19 2017, 12:53:05AM]:
> 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.
I even tried to make that sure, setting
boost::asio::ssl::context::tlsv12_server on the server side. Didn't change
much.
> 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.
I have overriden that method and kept only
CipherSuite.TLS_DHE_PSK_WITH_AES_128_CBC_SHA,
CipherSuite.TLS_RSA_PSK_WITH_AES_128_CBC_SHA
in the list. On the server side, I removed "PSK" alias and have set
PSK-AES128-CBC-SHA explicitly.
> 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).
Did that. Second method is never called. The first reports the following
exception.
And, when I look at the Wireshark log, the first client sends 114 bytes to
server
then the server immediately sends a zero-size chunk followed by FIN.
- $exception {"Attempted to read past the end of the
stream."} System.IO.EndOfStreamException
+ Data {System.Collections.ListDictionaryInternal}
System.Collections.IDictionary {System.Collections.ListDictionaryInternal}
HResult -2147024858 int
HelpLink null string
+ InnerException null System.Exception
Message "Attempted to read past the end of the stream." string
Source "BouncyCastle" string
StackTrace " at
Org.BouncyCastle.Crypto.Tls.TlsProtocol.SafeReadRecord() in
C:\\git\\bc-csharp\\crypto\\src\\crypto\\tls\\TlsProtocol.cs:line 493"
string
+ TargetSite {Void SafeReadRecord()}
System.Reflection.MethodBase {System.Reflection.RuntimeMethodInfo}
+ Static members
+ Non-Public members
I guess I have to turn on verbosity on OpenSSL side to get more clues, this is
just slightly PITA because of the ASIO wrapper inbetween.
> 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).
No worries, that hex string was supposed to be read as ASCII (I just picked the
next best tool, sha256sum, to create a dummy string of exactly 64 bytes length,
because originally I thought that problem might originate from different
padding of short key data).
> 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.
I am not an expect but wouldn't be surprised, it should be the best cipher from
the list of the PSK profile from
https://www.openssl.org/docs/man1.0.1/apps/ciphers.html .
Best regards,
Eduard.
