[openssl-users] Unable to STARTTLS behind a specific network

Thu Dec 22 16:58:34 UTC 2016

> On Dec 22, 2016, at 5:30 AM, Hoggins! <fuckspam at wheres5.com> wrote:
> 
> So what I do is :
> 
>    $ openssl s_client -starttls smtp -crlf -connect newdude.radiom.fr:5000

This (well essentially this, but with the Postfix "posttls-finger" utility)
works for me from my MTA host:

$ posttls-finger -d sha512 "[newdude.radiom.fr]:5000"
posttls-finger: using DANE RR: _5000._tcp.newdude.radiom.fr IN TLSA 3 0 2 95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12
posttls-finger: Connected to newdude.radiom.fr[188.165.117.231]:5000
posttls-finger: < 220 newdude.radiom.fr ESMTP Sendmail 8.15.2/8.15.2; Thu, 22 Dec 2016 17:54:11 +0100
posttls-finger: > EHLO mournblade.imrryr.org
posttls-finger: < 250-newdude.radiom.fr Hello mournblade.imrryr.org [38.117.134.19], pleased to meet you
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SIZE
posttls-finger: < 250-DSN
posttls-finger: < 250-ETRN
posttls-finger: < 250-AUTH GSSAPI LOGIN PLAIN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-DELIVERBY
posttls-finger: < 250 HELP
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: depth=0 matched end entity certificate sha512 digest 95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12
posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: Matched subjectAltName: *.radiom.fr
posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: subjectAltName: radiom.fr
posttls-finger: newdude.radiom.fr[188.165.117.231]:5000 CommonName *.radiom.fr
posttls-finger: newdude.radiom.fr[188.165.117.231]:5000: subject_CN=*.radiom.fr, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=95:6D:5F:68:4A:65:07:55:53:7D:14:02:2C:23:F4:A2:CD:5B:93:AC:86:94:E2:D5:16:26:21:24:B7:A9:06:E3:E1:E6:61:77:DF:60:6E:98:9E:36:9F:BA:23:11:CA:F9:53:99:79:73:0C:D9:D5:10:DF:73:92:52:60:B5:EA:12, pkey_fingerprint=C2:86:49:CF:64:12:52:13:CE:55:AD:84:D5:50:DF:88:42:0D:58:6D:78:B0:67:F6:F3:EE:D7:48:99:F6:28:A4:59:E4:97:08:EA:E6:DA:D8:92:92:28:C9:B8:4E:83:25:3E:1A:F6:CA:C9:94:5A:83:A7:3D:0C:9B:DA:F5:F0:37
posttls-finger: Verified TLS connection established to newdude.radiom.fr[188.165.117.231]:5000: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
posttls-finger: > EHLO mournblade.imrryr.org
posttls-finger: < 250-newdude.radiom.fr Hello mournblade.imrryr.org [38.117.134.19], pleased to meet you
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SIZE
posttls-finger: < 250-DSN
posttls-finger: < 250-ETRN
posttls-finger: < 250-AUTH GSSAPI LOGIN PLAIN
posttls-finger: < 250-DELIVERBY
posttls-finger: < 250 HELP
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 newdude.radiom.fr closing connection

> No problem, I can communicate with the SMTP server after the STARTTLS
> occurred.
> 
> But behind that specific network, if I run the same command, all I get is :
> 
>    CONNECTED(00000003)
>    write:errno=104
>    ---
>    no peer certificate available
>    ---
>    No client certificate CA names sent
>    ---
>    SSL handshake has read 351 bytes and written 147 bytes
>    ---
>    New, (NONE), Cipher is (NONE)
>    Secure Renegotiation IS NOT supported
>    Compression: NONE
>    Expansion: NONE
>    ---
> 
> When I compare two tcpdumps, I can clearly see that a lot of data is
> missing, the transaction is not complete.
> 
> Before being paranoid, I simply suspect a MTU problem, but I'm not sure
> how this would only apply to SSL transactions.
> 
> Should I provide tcpdumps or anything else?

Just the PCAP file for the broken session is enough.  However, since the
destination looks perfectly fine, the problem is surely some firewall at
the source network that exhibits the problem, and figuring out exactly
what's wrong with that firewall is not an OpenSSL issue.  Send the PCAP
file to the network administrator and ask for help there.

-- 
	Viktor.