On Sun, Jul 15, 2018 at 4:41 PM, Gareth Williams <gareth at garethwilliams.me.uk> wrote: > > On 14/07/2018 21:06, Nikos Mavrogiannopoulos wrote: >> >> Unfortunately, it is only heuristics you can try here. It could be >> that the middlebox doesn't understand a particular extension, or some >> particular ciphersuite, or doesn't like the hello size. Try a smaller >> ciphersuite list as: >> >> "NORMAL:-SHA256:-SHA384:-3DES-CBC:-DHE-DSS:-SIGN-DSA-SHA1:-SIGN-DSA-SHA256:-SIGN-DSA-SHA384:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC:-CAMELLIA-128-GCM:-CAMELLIA-256-GCM" >> >> And/or combinations of that list (i.e., re-enabling DSS/DSA if you >> need it). That's the list of algorithms which are already disabled in >> 3.6.2 (some also from the unreleased 3.6.3) versions of gnutls. Would >> that improve the situation? If not you can go further by trying >> options for specific extensions such as %NO_ETM, >> %DISABLE_SAFE_RENEGOTIATION, %NO_SESSION_HASH, %NO_TICKETS etc. If any >> of these help improve the situation let me know. > > > Hi Nikos, > > I tried various combinations and came to the conclusion that the only > extension that differ between gnutls-cli working (with the > --disable-extensions option) and failing was server_name. I then noticed > that gnutls-cli has the --disable-sni option. I therefore tried the > following: > > gnutls-cli --no-ca-verification <hostname>, and the connection failed as > expected. > > gnutls-cli --no-ca-verification --disable-sni <hostname>, and it works (no > need for Priority Strings by the way) > > Then, to add confusion I added server_name to openssl's s_client Client > Hello: > > openssl s_client -servername <hostname> -connect <hostname>:443, and oddly > that worked. > > Therefore it seems the problem is down to the server_name TLS extension but > only when the client is gnutls. I compared the hex dumps (from Wireshark) > of the extension from gnutls-cli and openssl s_client and they are > identical. The only difference I noticed was the ordering of the extensions > - when using gnutls-cli the extension is 4th in the extension list (behind > extended_master_secret, encrypt_then_mac and status_request) while for > openssl s_client the server_name extension is the 1st in the list. Could > that make a difference? Protocol-wise it shouldn't make a difference. That's very odd though, do browsers work there? If yes, it may be that there is a buggy middle box, or a middle box which is fingerprinting to block VPNs (the latter you can rule out if openvpn works). regards, Nikos
