SERVER SSL profile ciphers work fine, but not HTTPS monitor

Perhaps you need to put DEFAULT: in front of the cipher string. i.e:

DEFAULT:!SSLv2:!TLSv1_2:!TLSv1_1:!EXPORT:!DH:RSA+RC4:RSA+AES:RSA+DES:RSA+3DES:ECDHE+AES:ECDHE+3DES:@SPEED

Thanks for the suggestion. I just tried it, but unfortunately, it does not work any better.

Tom

and ssldump shows a successful SSL negociation with Application data

So then are you JUST changing the cipher list to make it fail? Does that change what you see in the SSLDUMP?

Hi Kevin,

thanks for your reply.

It's my mistake .... I had another service being monitored on the same host but on another port and I was capturing both monitors' traffic.

So there actually is a difference between the two SSLdumps. With the same cipher list as in the SSL profile, I get :

New TCP connection 92: *f.5.f.5*(55660) <-> *s.s.s.s* (7002)
92    0.0026 (0.0026)  C>S  TCP FIN
92    0.0035 (0.0009)  S>C  TCP FIN

whereas with only "AES256-SHA", I get a full connection :

   New TCP connection 2: *f.5.f.5*(51943) <-> *s.s.s.s* (7002)
   2 1  0.0016 (0.0016)  C>SV3.1(48)  Handshake
          ClientHello
            Version 3.1
            random[32]=
              52 fd 17 4b d9 6a 38 f4 1d 08 47 95 b8 ce 78 6e
              96 a0 08 14 53 c1 43 01 65 96 49 57 42 ea 59 ea
            cipher suites
            TLS_RSA_WITH_AES_256_CBC_SHA
            Unknown value 0xff
            compression methods
                    unknown value
                      NULL
    2 2  0.0039 (0.0022)  S>CV3.1(58)  Handshake
          ServerHello
            Version 3.1
            random[32]=
              52 fd 17 4b c5 af 94 91 bd 40 97 5a e9 49 a6 1b
              f5 f1 8e 4a 6b 84 c5 db 92 3b e5 0d 03 85 e5 2f
            session_id[16]=
              0e af 8d 97 60 c8 bd 90 00 be 75 43 94 4c a9 7b
            cipherSuite         TLS_RSA_WITH_AES_256_CBC_SHA
            compressionMethod                   NULL
    2 3  0.0042 (0.0002)  S>CV3.1(2475)  Handshake
          Certificate
    2 4  0.0042 (0.0000)  S>CV3.1(4)  Handshake
          ServerHelloDone
    2 5  0.0053 (0.0011)  C>SV3.1(262)  Handshake
          ClientKeyExchange
            EncryptedPreMasterSecret[256]=
              24 aa 03 6f ba 78 2b fb 7e 11 d6 05 88 70 7a c4
              66 a1 a3 8a 0d fb fe 18 bb a7 b6 c9 71 8d 96 31
              da b9 b0 ae cd c0 4f bf 76 62 05 69 cd cc 53 89
              13 ff 82 36 ea 18 31 4c f5 65 7d 68 c9 d8 16 98
              18 96 95 ca 52 d6 fd f3 31 24 14 6b a9 0e 53 1d
              37 f5 4e e1 b3 88 09 f4 34 d7 7e 8e d4 59 0d 2a
              56 27 b5 3b c3 10 4b 96 75 58 8f 59 ae 38 25 fe
              51 36 29 7d e5 6b af f3 9c f0 b7 e3 6f 25 63 1e
              c2 1e 94 0d 63 d8 d5 84 05 4e 31 2e 10 f2 17 0f
              cd 5c 79 bc c4 19 7a 36 b1 02 4b 36 b3 e4 eb 9d
              5b 34 51 ab 00 a2 f4 1d f7 b8 10 bd 41 23 1d da
              5a 94 85 4c 85 e6 66 5d 83 40 94 17 81 68 0f 22
              1b 36 5c 4f 8f ab 1d d7 e9 36 31 4b 08 a4 69 44
              73 31 80 f2 f2 71 54 68 44 9f a3 44 73 8e 46 a3
              dc d0 75 d0 a0 d8 3d fb 19 69 0c 1b a2 d9 2a 9b
              f4 25 ef 54 1f 37 f0 b5 13 f4 98 21 bc 76 0c f2
    2 6  0.0053 (0.0000)  C>SV3.1(1)  ChangeCipherSpec
    2 7  0.0053 (0.0000)  C>SV3.1(48)  Handshake
    2 8  0.0236 (0.0182)  S>CV3.1(1)  ChangeCipherSpec
    2 9  0.0236 (0.0000)  S>CV3.1(48)  Handshake
    2 10 0.0245 (0.0009)  C>SV3.1(96)  application_data
    2 11 0.1131 (0.0885)  S>CV3.1(32)  application_data
    2 12 0.1131 (0.0000)  S>CV3.1(448)  application_data
    2 13 0.1133 (0.0002)  S>CV3.1(32)  application_data
    2 14 0.1133 (0.0000)  S>CV3.1(560)  application_data
    2 15 0.1133 (0.0000)  S>CV3.1(32)  application_data
    2 16 0.1133 (0.0000)  S>CV3.1(32)  application_data
    2 17 0.1133 (0.0000)  S>CV3.1(32)  Alert
    2 18 0.1136 (0.0002)  C>SV3.1(32)  Alert
    2    0.1136 (0.0000)  S>C  TCP FIN
    2    0.1140 (0.0003)  C>S  TCP RST

I still don't get why I can't use the same cipher list syntax in both the SSL server profile and the HTTPS monitor...

And yes, the cipher list is the only thing I change.

If you have any suggestion, that would be greatly appreciated.

Thanks

Tom

A couple other interesting tests and results :

• RC4-MD5 : full SSL connection - monitor OK
• RC4-MD5:AES256-SHA:@SPEED : failure
• RC4-MD5:AES256-SHA:@STRENGTH : full SSL connection - monitor OK(CLIENT HELLO offers AES-256-SHA and RC4-128-MD5, SERVER HELLO uses RC4-128-MD5)

changing the cipher ordering for @STRENGTH in my initial cipher string does not do any good though.

that's really a weird behaviour...

Try the more traditional OpenSSL cipher syntax:

!SSLv2:!TLSv1.2:!TLSv1.1:!EXPORT:!DH:RSA+RC4:RSA+AES:RSA+DES:RSA+3DES:ECDHE+AES:ECDHE+3DES:@STRENGTH

Neither cURL/OpenSSL, nor apparently the monitor cipher list likes the @SPEED option, plus the underscores in the clientSSL profile need to be changed to periods.

I tried with the string you suggested and it did not work.

I then did some trial and error and isolated the string which caused the failure.

Whenever I use !TLSv1.1, !TLSv1.2, !TLSv1_1 or !TLSv1_2, it fails.

It worked with the following string :

!SSLv2:!EXPORT:!DH:RSA+RC4:RSA+AES:RSA+DES:RSA+3DES:ECDHE+AES:ECDHE+3DES:@STRENGTH

The same string with

@SPEED

I was surprised that the client hello was sent with protocol version 3.1 (TLS 1.0) whereas the actual connection to the server uses protocol version 3.3 (TLS 1.2) by default (if I don't specify !TLSv1_2 in the cipher string).

Obviously, the monitor does not use the same SSL implementation as the SSL server profiles ...

Thanks for your help Kevin !

Tom

PS: this is the behaviour on 11.4.1 HF2, I'll try 11.5.0 soon, I might get different results.

I just used my version of the string on an 11.5 box, so I'm pretty certain that works. One alternative might also be to do this in an external script monitor and use cURL with the --ciphers option.

Could you please provide external monitor script

Take a look at the sample Bash script monitor at

/config/monitors/sample_monitor