[openssl-users] re-negotiated master key in s_client
I am using openssl command line client (s_client) and wireshark to identify the behaviour of a server that enforces secure renegotiation for client certificate verification. Since the Master-Key is printed along with SSL-Session information, I am able to use it in wireshark to decrypt the messages up to re-negotiation. Is there a way to get s_client to print the renegotiated Master-Key ? Vysakh P Pillai http://embeddedinn.github.io -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Help with ssl error
> On Apr 19, 2017, at 12:48 PM, Joseph Southwell> wrote: > > Sorry we did do that. It just didn’t look different so I didn’t send it > (pasted below). I also have asked for help from the server admin but it is a > non English speaking country and they don’t seem to be interested in talking > to me. I have another product supposedly using OpenSSL that is currently > working fine so it must be possible. That product is using 0.9.8something. The "0.9.8something" releases support RC4, 3DES, export ciphers, ... OpenSSL 1.1.0 does not by default include any of these. You can get RC4 and 3DES by compiling with weak ciphers enabled, the EXPORT ciphers are expunged from the code. > So specifying -cipher "AES128-SHA” will cause it to not use DHE? Yes, it will offer just that single ciphersuite "0x002f" and nothing else. If that does not work, the claim that the server supports RSA with AES-128-CBC is not credible. To find out what it does support, build OpenSSL 1.0.2, and try connecting with that version of "s_client". Another thing to try is sending an SNI name (-servername ...), perhaps the server wants to see that, though it seems very unlikely for FTP. You could also try restricting the protocol to TLS 1.0, perhaps the server mishandles TLS 1.2 and/or TLS 1.1: ... -no_tls1_2 -no_tls1_1 -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Help with ssl error
Sorry we did do that. It just didn’t look different so I didn’t send it (pasted below). I also have asked for help from the server admin but it is a non English speaking country and they don’t seem to be interested in talking to me. I have another product supposedly using OpenSSL that is currently working fine so it must be possible. That product is using 0.9.8something. So specifying -cipher "AES128-SHA” will cause it to not use DHE? openssl s_client -state -msg -cipher "ALL" -connect ftp.echannel.banksys.be:16370 -starttls ftp CONNECTED(0104) SSL_connect:before SSL initialization >>> ??? [length 0005] 16 03 01 00 f7 >>> TLS 1.2Handshake [length 00f7], ClientHello 01 00 00 f3 03 03 da ac 89 55 94 51 e0 ce 4b 3b ec ee 33 fd 31 1f 75 f1 50 1a 50 73 09 07 5a 0e cf 7d c3 ac 54 03 00 00 84 c0 2c c0 30 00 a3 00 9f cc a9 cc a8 cc aa c0 af c0 ad c0 a3 c0 9f c0 2b c0 2f 00 a2 00 9e c0 ae c0 ac c0 a2 c0 9e c0 24 c0 28 00 6b 00 6a c0 73 c0 77 00 c4 00 c3 c0 23 c0 27 00 67 00 40 c0 72 c0 76 00 be 00 bd c0 0a c0 14 00 39 00 38 00 88 00 87 c0 09 c0 13 00 33 00 32 00 9a 00 99 00 45 00 44 00 9d c0 a1 c0 9d 00 9c c0 a0 c0 9c 00 3d 00 c0 00 3c 00 ba 00 35 00 84 00 2f 00 96 00 41 00 07 00 ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00 16 00 00 00 17 00 00 SSL_connect:SSLv3/TLS write client hello <<< ??? [length 0005] 15 03 02 00 02 <<< TLS 1.2Alert [length 0002], fatal insufficient_security 02 47 SSL3 alert read:fatal:insufficient security SSL_connect:error in SSLv3/TLS write client hello 2152:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71 > On Apr 19, 2017, at 11:43 AM, Viktor Dukhovni> wrote: > > On Tue, Apr 18, 2017 at 05:06:40PM +, Viktor Dukhovni wrote: > >> The ClientHello decodes via tshark as: >> >> [...] >>Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) >>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) >>Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) >>Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) >> [...] >> >> This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should >> be broadly interoperable. The DEFAULT cipherlist includes only >> AES, is there a chance that the server only supports RC4 and/or >> 3DES? >> >> Try: >> >>$ openssl s_client -state -msg -cipher ALL \ >>-connect ftp.echannel.banksys.be:16370 -starttls ftp >> >> Capture a PCAP file of the traffic with >> >># tcpdump -s0 -w /some/file tcp port 16370 >> >> and post the the decode from: >> >>$ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V | >>sed -ne '/^Secure Sockets Layer/,/^$/p' >> >> Or just attach the PCAP file to your follow-up message. > > On Wed, Apr 19, 2017 at 10:53:27AM -0400, Joseph Southwell wrote: > >> Is there a way to enable one or both of those ciphers in OpenSSL? >> >>> On Apr 18, 2017, at 1:28 PM, Jason Schultz wrote: >>> >>> RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA > > With so many different names for the underlying TLS ciphersuites > one can only guess which ones are the same. That said, I'd say > that the first one on your list is enabled by default, and was used > in your TLS ClientHello (TLS_RSA_WITH_AES_128_CBC_SHA 0x002f). > > It is possible that (despite any claims to the contrary) the server > only supports the 3DES ciphersuite above, in which case you need > either OpenSSL 1.0.2 or a build of OpenSSL 1.1.0 with the Configure > option "--enable-weak-ssl-ciphers". The 3DES TLS ciphers are by > default disabled at compile-time in OpenSSL 1.1.0 and later. > > I did suggest the "-cipher ALL" option as a first place to start to > find out what the server actually supports. I'm puzzled as to why > you've not tried that yet. > > A more exotic scenario is that the server is configured with a weak > DHE group and having chosen DHE decides that the group is too weak. > In that case you could try just the purported AES cipher: > > -cipher "AES128-SHA" > > The name was obtained via: > >$ openssl ciphers -V ALL | grep 0x00,0x2F > 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA > Enc=AES(128) Mac=SHA1 > > Finally, you really should ask for help from the server administrator > they should have useful data in their logs. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-users Digest, Vol 29, Issue 20
After some debugging (exactly as mentioned above) it appears that the cipher suite does not show up in the ClientHello using the s_client/s_server. I modified the cipher for testing to use 512 bits instead of 64 so that it is ranked highest. Error server side: SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:1979 Error Client side: SSL routines:ssl3_read_bytes:tlsv1 alert internal error:ssl/record/rec_layer_s3.c:1469:SSL alert number 80 Any idea why the cipher would appear under the list of supported tls1.2 ciphers, yet it does not appear under the ClientHello even if specified with the -cipher option? Hmm... it's not clear why the cipher isn't being sent in client hello. What output do you get with -security_debug_verbose option? Also try including @SECLEVEL=0 in the cipher string. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org The -security_debug_verbose option confirmed it was not being sent in the client hello. Here is the s_server command used: openssl s_server -accept 6000 -tls1_2 -cert ./cert.pem -key ./key.pem -state -debug -msg -security_debug_verbose -cipher 'ECDHE-RSA-MYCIPHER-SHA256:@SECLEVEL=0' Output: Using default temp DH parameters Security callback: Certificate chain EE key=RSA, bits=4096, security bits=128: yes ACCEPT Security callback: Version=TLS 1.3: yes SSL_accept:before SSL initialization read from 0x55613d95d540 [0x55613d962b23] (5 bytes => 5 (0x5)) - 16 03 01 00 77w <<< ??? [length 0005] 16 03 01 00 77 read from 0x55613d95d540 [0x55613d962b28] (119 bytes => 119 (0x77)) - 01 00 00 73 03 03 fa d8-cc c4 e4 fb 70 c1 49 95 ...sp.I. 0010 - fe 21 20 76 b1 78 2a b9-db 5f b7 af b8 de 9a 2c .! v.x*.._., 0020 - 5e de 74 d1 8f 66 00 00-04 c0 9c 00 ff 01 00 00 ^.t..f.. 0030 - 46 00 0b 00 04 03 00 01-02 00 0a 00 0a 00 08 00 F... 0040 - 1d 00 17 00 19 00 18 00-23 00 00 00 0d 00 20 00 #. . 0050 - 1e 04 03 05 03 06 03 08-04 08 05 08 06 04 01 05 0060 - 01 06 01 02 03 02 01 02-02 04 02 05 02 06 02 00 0070 - 16 00 00 00 17. 0077 - SSL_accept:before SSL initialization <<< TLS 1.3, Handshake [length 0077], ClientHello 01 00 00 73 03 03 fa d8 cc c4 e4 fb 70 c1 49 95 fe 21 20 76 b1 78 2a b9 db 5f b7 af b8 de 9a 2c 5e de 74 d1 8f 66 00 00 04 c0 9c 00 ff 01 00 00 46 00 0b 00 04 03 00 01 02 00 0a 00 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 00 0d 00 20 00 1e 04 03 05 03 06 03 08 04 08 05 08 06 04 01 05 01 06 01 02 03 02 01 02 02 04 02 05 02 06 02 00 16 00 00 00 17 00 00 Security callback: Version=TLS 1.2: yes Security callback: : yes Security callback: Shared Signature Algorithm digest=SHA256, algorithm=ECDSA, security bits=128: yes Security callback: Shared Signature Algorithm digest=SHA384, algorithm=ECDSA, security bits=192: yes Security callback: Shared Signature Algorithm digest=SHA512, algorithm=ECDSA, security bits=256: yes Security callback: Shared Signature Algorithm digest=SHA256, algid=4, security bits=128: yes Security callback: Shared Signature Algorithm digest=SHA384, algid=5, security bits=192: yes Security callback: Shared Signature Algorithm digest=SHA512, algid=6, security bits=256: yes Security callback: Shared Signature Algorithm digest=SHA256, algorithm=RSA, security bits=128: yes Security callback: Shared Signature Algorithm digest=SHA384, algorithm=RSA, security bits=192: yes Security callback: Shared Signature Algorithm digest=SHA512, algorithm=RSA, security bits=256: yes Security callback: Shared Signature Algorithm digest=SHA1, algorithm=ECDSA, security bits=80: yes Security callback: Shared Signature Algorithm digest=SHA1, algorithm=RSA, security bits=80: yes Security callback: Shared Signature Algorithm digest=SHA1, algorithm=DSA, security bits=80: yes Security callback: Shared Signature Algorithm digest=SHA256, algorithm=DSA, security bits=128: yes Security callback: Shared Signature Algorithm digest=SHA384, algorithm=DSA, security bits=192: yes Security callback: Shared Signature Algorithm digest=SHA512, algorithm=DSA, security bits=256: yes Security callback: Shared Signature Algorithm digest=SHA256, algorithm=ECDSA, security bits=128: yes Security callback: Shared Signature Algorithm digest=SHA384, algorithm=ECDSA, security bits=192: yes Security callback: Shared Signature Algorithm digest=SHA512, algorithm=ECDSA, security bits=256: yes Security callback: Shared Signature Algorithm digest=SHA256, algid=4, security bits=128: yes Security callback: Shared Signature Algorithm digest=SHA384, algid=5, security bits=192: yes Security callback: Shared Signature Algorithm digest=SHA512, algid=6, security bits=256: yes Security callback: Shared Signature Algorithm digest=SHA256, algorithm=RSA, security
Re: [openssl-users] Help with ssl error
On Tue, Apr 18, 2017 at 05:06:40PM +, Viktor Dukhovni wrote: > The ClientHello decodes via tshark as: > > [...] > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) > Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) > Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) > [...] > > This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should > be broadly interoperable. The DEFAULT cipherlist includes only > AES, is there a chance that the server only supports RC4 and/or > 3DES? > > Try: > > $ openssl s_client -state -msg -cipher ALL \ > -connect ftp.echannel.banksys.be:16370 -starttls ftp > > Capture a PCAP file of the traffic with > > # tcpdump -s0 -w /some/file tcp port 16370 > > and post the the decode from: > > $ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V | > sed -ne '/^Secure Sockets Layer/,/^$/p' > > Or just attach the PCAP file to your follow-up message. On Wed, Apr 19, 2017 at 10:53:27AM -0400, Joseph Southwell wrote: > Is there a way to enable one or both of those ciphers in OpenSSL? > > > On Apr 18, 2017, at 1:28 PM, Jason Schultzwrote: > > > > RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA With so many different names for the underlying TLS ciphersuites one can only guess which ones are the same. That said, I'd say that the first one on your list is enabled by default, and was used in your TLS ClientHello (TLS_RSA_WITH_AES_128_CBC_SHA 0x002f). It is possible that (despite any claims to the contrary) the server only supports the 3DES ciphersuite above, in which case you need either OpenSSL 1.0.2 or a build of OpenSSL 1.1.0 with the Configure option "--enable-weak-ssl-ciphers". The 3DES TLS ciphers are by default disabled at compile-time in OpenSSL 1.1.0 and later. I did suggest the "-cipher ALL" option as a first place to start to find out what the server actually supports. I'm puzzled as to why you've not tried that yet. A more exotic scenario is that the server is configured with a weak DHE group and having chosen DHE decides that the group is too weak. In that case you could try just the purported AES cipher: -cipher "AES128-SHA" The name was obtained via: $ openssl ciphers -V ALL | grep 0x00,0x2F 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 Finally, you really should ask for help from the server administrator they should have useful data in their logs. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Help with ssl error
Is there a way to enable one or both of those ciphers in OpenSSL? > On Apr 18, 2017, at 1:28 PM, Jason Schultzwrote: > > RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Network problems (not OpenSSL)
> On Apr 19, 2017, at 10:39 AM, Lasse Thorbro-Steenberg >wrote: > > Using Wireshark I can see the TCP window remains open, but after a few > seconds on 2mbs the server start fragmenting IP packets which completely > drops the throughput to around 1 mbs. > Data is delivered successfully even with fragmentation, but the effective > throughput achievable on the link drops significantly. OpenSSL does not implement TCP/IP, and network throughput issues need to solved at the network layer. You may have path MTU issues, or other networking problems. If smaller than the MTU writes are done back to back, you may want to disable Nagle's algorithm via the appropriate setsockopt() call (enable TCP_NDELAY). You should be able to see the same throughput issues just sending data (similarly chunked) in the clear without OpenSSL. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl
Hi, New to this list! I am using Openssl in a project that send large amounts of data in bursts from a windows 2008 server to an Ubuntu 16.04 client. It works well with low data rates (<1mbs) but when mean data rates hits around 2 mbs, things get ugly. I use blocking wrtite calls and my buffers overflow after a while at 2mbs. Using Wireshark I can see the TCP window remains open, but after a few seconds on 2mbs the server start fragmenting IP packets which completely drops the throughput to around 1 mbs. Data is delivered successfully even with fragmentation, but the effective throughput achievable on the link drops significantly. Has anyone seen this type of issue before ? Thanks, Lasse -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_shutdown return error when close in init
On 19/04/2017 14:35, Salz, Rich via openssl-users wrote: The OpenSSL documentation makes it clear that you must keep calling the same asynchronous function with the same parameters until the async job has completed. Is there a way we can (relatively cheaply) check for that type of programming error and return an "in progress on another op" error? Also, for the shutdown case, it would be nice (in general) if attempting shutdown during a handshake will make the handshake abort as soon as the protocol allows, rather than going through all the remaining steps and their transmissions. In other words, returning appropriate errors/alerts to the other end according to the handshake step. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Query regarding DTLS handshake
For those following this discussion Mahesh has created a github issue with much more detail (at least I am assuming this is the same issue): https://github.com/openssl/openssl/issues/3251 Matt On 18/04/17 21:17, Michael Tuexen wrote: >> On 13. Apr 2017, at 11:11, mahesh gswrote: >> >> Hi, >> >> We are running SCTP connections with DTLS enabled in our application. We >> have adapted openssl version (openssl-1.1.0e) to achieve the same. >> >> We have generated the self signed root and node certificates for testing. We >> have a strange problem with the incomplete DTLS handshake if we run the DTLS >> client and DTLS server is different systems.If we run the DTLS client and >> server in same system handshake is successful, handshake is not successful >> if run client and server in different VM's. >> >> This strange problem happens only for SCTP/DTLS connection. With the same >> set of certificates TCP/TLS connection is successful and we are able to >> exchange the application data. >> >> I am attaching the code bits for SSL_accept and SSL_connect and also the >> wireshark trace of unsuccessful handshake. Please assist me to debug this >> problem. >> >> SSL_accept returns SSL_ERROR_WANT_READ(2) infinite times but SSL_connect is >> called 4 or 5 times and select system call timeout. > Which OS are you using? With a test program I could reproduce SSL_accept() > returning SSL_ERROR_WANT_READ under FreeBSD, > but not under Linux. Haven't figured out what the problem is. So if you are > using FreeBSD we might experience the same problem... > > Best regards > Michael >> >> Thanks, >> Mahesh G S >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_shutdown return error when close in init
> The OpenSSL documentation makes it clear > that you must keep calling the same asynchronous function with the same > parameters until the async job has completed. Is there a way we can (relatively cheaply) check for that type of programming error and return an "in progress on another op" error? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users