FREAK - Microsoft workaround seems to break Network Connect?

[Korereactor_]

Also, I'll add - I am applying this to the LOCAL group policy on the test machines, not via network group policies.

[Korereactor_]

One additional update, I've been able to reproduce this on a third machine, a brand new one, same issue, totally different hardware.  Disabling the group policy fixes it.

[flip_pipe_]

Hi Korereactor,

I've be able to replicate the problem.

If you compare the cipher suites provided by Secure Access and the ones by Microsoft, there is no overlap.

In matter of fact, in SA event logs you have something like this:

2015-03-10 10:13:59 - ive - [XXX.XXX.XXX.XXX] Root:ystem()[] - SSL negotiation failed while client at source IP 'XXX.XXX.XXX.XXX' was trying to connect to 'XXX.XXX.XXX.XXX'. Reason: 'no shared cipher'

If you do a capture of traffic and output with SSLDUMP you get:

New TCP connection #19: XXX.XXX.XXX.XXX(49603) <-> XXX.XXX.XXX.XXX(443)
19 1  0.0132 (0.0132)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        compression methods
                  NULL
        ClientHello Extensions [60]=
          00 3a ff 01 00 01 00 00 00 00 19 00 17 00 00 14
          74 73 74 2d 75 73 65 72 73 2e 76 70 6e 2e 6e 6f
          73 2e 70 74 00 0d 00 14 00 12 04 01 05 01 06 01
          02 01 04 03 05 03 06 03 02 03 02 02
19 2  0.0134 (0.0001)  S>C  Alert
    level           fatal
    value           handshake_failure
19    0.0135 (0.0000)  S>C  TCP FIN
19    0.0291 (0.0155)  C>S  TCP RST

We only allow TLS with AES and AES/3DES in out Secure Access boxes.

Even lowering the ciphers to allow SSL with DES and RC4 I still get in the logs

2015-03-10 10:28:24 - ive - [XXX.XXX.XXX.XXX] Root:ystem()[] - SSL negotiation failed while client at source IP 'XXX.XXX.XXX.XXX' was trying to connect to 'XXX.XXX.XXX.XXX'. Reason: 'no shared cipher'

My testes where done againts a SA2500 with 8.0R9.

Regards,

[Kita_]

Hello Flip,

When I enabled TLS with AES and AES/DES, it is telling me the following cipher suites will be enabled on the SA.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

When i connect via my client, I am connecting by the last two cipher suites.  I think there is something wrong with my GP. Let me see if I can test this again.

[Kita_]

After further testing, I am able to see the same results in our lab with only the workaround solution.  If I remove the workaround and apply the MS patch, there are no issues.  We will look into this internally to see what we can do to help prevent this issue in the future, but the recommendation is not to apply the workaround.