Mis-fingerprinting with certain OpenSSL configurations

[BenBE]

I'm not entirely sure what's going on with the fingerprinting of my blog, but my purse told me I did not by any FortiOS devices for https://blog.benny-baumann.de - instead it's running a nginx on Debian (testing).

$ ./prober.py blog.benny-baumann.de
FortiOS v5.2.2,build642 (GA)    12
openssl-1.0.1h default source build 7
openssl-1.0.1c default source build 7
openssl-1.0.1e default source build 7
F5 FirePass 6.1.0 URM-6.10-20091009 7

$ ./prober.py -l blog.benny-baumann.de
    ZeroHelloVersion    error:ECONNRESET|
      BadContentType    *(5454)record:type(48)|error:Unexpected EOF receiving record header - server closed connection|
        SNIEmptyName    *(301)alert:DecodeError:fatal|
   SplitHelloRecords    *(5454)record:type(48)|error:Unexpected EOF receiving record header - server closed connection|
         EmptyRecord    error:ECONNRESET|
RecordLengthUnderflow   writeerror:ECONNRESET|
          Heartbleed    *(301)alert:HandshakeFailure:fatal|
 BadHandshakeMessage    *(301)alert:HandshakeFailure:fatal|
     NormalHandshake    *(301)alert:HandshakeFailure:fatal|
  OnlyECCipherSuites    *(301)handshake:ServerHello(301)|*(301)handshake:Certificate|*(301)handshake:ServerKeyExchange|*(301)handshake:ServerHelloDone|
           NoCiphers    *(301)alert:IllegalParameter:fatal|
  VeryHighTLSVersion    error:ECONNRESET|
VeryHighHelloVersion    *(303)handshake:ServerHello(303)|*(303)handshake:Certificate|*(303)handshake:ServerHelloDone|
   DoubleClientHello    *(301)alert:HandshakeFailure:fatal|
           Heartbeat    *(301)alert:HandshakeFailure:fatal|
      HighTLSVersion    error:ECONNRESET|
    HighHelloVersion    *(303)handshake:ServerHello(303)|*(303)handshake:Certificate|*(303)handshake:ServerHelloDone|
   SplitHelloPackets    *(301)alert:HandshakeFailure:fatal|
EmptyChangeCipherSpec   *(301)alert:HandshakeFailure:fatal|
RecordLengthOverflow    error:timeout
    ChangeCipherSpec    *(301)alert:HandshakeFailure:fatal|
        SNIWrongName    *(301)alert:HandshakeFailure:fatal|
         SNILongName    *(301)alert:UnrecognizedName:fatal|
      ZeroTLSVersion    error:ECONNRESET|

The server is running:

# openssl version
OpenSSL 1.0.1k 8 Jan 2015

# dpkg -s nginx-full | grep -ix '[PV].*'
Package: nginx-full
Version: 1.6.2-5

The basic template for the nginx SSL config basically looks like:

ssl_protocols               TLSv1.2 TLSv1.1 TLSv1;
ssl_prefer_server_ciphers   on;
ssl_ciphers                 HIGH:+CAMELLIA256:!eNull:!aNULL:!ADH:!MD5:-RSA+AES+SHA1:!RC4:!DES:!3DES:!SEED:!EXP:!AES128:!CAMELLIA128;

ssl_session_cache           shared:SSL:16m;
ssl_session_timeout         5m;
ssl_session_tickets         on;
ssl_session_ticket_key      /etc/nginx/sessions.d/current.key;

ssl_client_certificate      /etc/ssl/certs/ca-certificates.pem;
ssl_trusted_certificate     /etc/nginx/trusted-ca.pem;

#ssl_verify_client           optional_no_ca;
ssl_verify_client           off;
ssl_verify_depth            5;

ssl_stapling                on;
ssl_stapling_verify         on;

ssl_dhparam                 /etc/ssl/dh/server13337.dh.pem;

#ssl_certificate             /etc/ssl/public/   $server_name.crt;
#ssl_certificate_key         /etc/ssl/private/  $server_name.key;

The used certificates are 8192 bit RSA. The used DH parameters are as indicated in the filenames.

[Richard Moore]

Well, that's a pretty weird config you have. Currently the prober does not use any PFS cipher suites (these require different fingerprints to non-PFS ones). Long term I suspect doing a pass with PFS suites in addition to the current one with non-PFS would be a good way to resolve this (at the cost of speed).

Enabling camellia however is just weird. No idea why you're doing that.

[BenBE]

Good to know there is a likely suspect for this behavior.

Side node on Camellia: It's to avoid AES monoculture AND Camellia is as good as AES (for the protection I care). Need to get ChaCha20 into the list at some time too. Also: As AES is the bigger target (more users) it's more likely of being attacked by dragnet operations (higher gain at similar costs). Regarding param size: They are scaled for 192 Bit symmetric security according to recommendations by ETSI (assuming network traffic might end up being stored for later analysis).

P.S.: /me loves to break crypto stuff for fun and profit ;-)

[Aaron Zauner]

@BenBE
Then again, any attacks that break AES probably break CAMELLIA as well. AES has the added benefit of platform hardware support on most modern general purpose x86_64 CPUs (Intel, AMD). I'd also suspect that a 8k RSA key breaks some browsers ;)

[BenBE]

@azet Actually 8k RSA works quite well (except on Apple Safari where it freezes/crashes the browser*).
Camellia is currently the only viable alternative while ChaCha20 is not included with OpenSSL - thus should do for now. Well, back to topic of this ticket :)

• which I don't care about; they should fix their implementation - and they have been aware of this issue for years now.

[Aaron Zauner]

(yea, kinda off-topic)

@BenBE right. Safari doesn't work. This is a big user base you're excluding, why not use ECDSA or 4k RSA?

CAMELLIA isn't really an alternative. TLS also supports ARIA FYI, but nobody uses it. CAMELLIA and ARIA are essentially in the spec. because asian goverments depend on these ciphers (they're mandated by policy in Japan and Korea). I'm not a block cipher cryptanalyst but ARIA is based on AES and CAMELLIA uses a feistel-network, so if there are big advances in cryptanalysis regarding AES, both of these ciphers are affected as well.

..and of course, you lose any crypto speedup by AESNI.

BTW, with a current Chrome - I can't even opt in to view your blog.