search

usnistgov / ACVP

Industry Working Group on Automated Cryptographic Algorithm Validation
https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program
169 stars 66 forks source link

New public code differences from previous implementation #861

Closed Kritner closed 4 years ago

Kritner commented 4 years ago

With the rewrite of the public code (now on demo), there are a few minor differences from the previous implementation. These differences may change a few requirements on requests/responses to/from the client.

I will continue to update this issue if any other differences are found that clients should take into account.

AlexThurston commented 4 years ago

I might be missing something, but I can't seem to authenticate anymore.

POST https://demo.acvts.nist.gov/acvp/v1/login

With a body of:

 [{"acvVersion": "1.0"}, {"password": <TOTP>}]

If I try the same thing with CURL, I get a standard Access Denied page returned.

smuellerDD commented 4 years ago

I cannot confirm that - authentication works for me.

jarnold01 commented 4 years ago

I might be missing something, but I can't seem to authenticate anymore.

POST https://demo.acvts.nist.gov/acvp/v1/login

With a body of:

 [{"acvVersion": "1.0"}, {"password": <TOTP>}]

If I try the same thing with CURL, I get a standard Access Denied page returned.

Hi Alex,

Thanks for letting us know. Would you mind sending me an email (jason.arnold@nist.gov) with the Subject line pasted in from the certificate you are using please?

smuellerDD commented 4 years ago

Alex, one hint to your issue: could it be that the enforcement of the TOTP step size causes the issue for you?

AlexThurston commented 4 years ago

I don’t think so. I just checked my implementation and it seems to be correctly passing the 30 second step size.

On Sun, May 24, 2020 at 6:47 AM smuellerDD notifications@github.com wrote:

Alex, one hint to your issue: could it be that the enforcement of the TOTP step size causes the issue for you?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-633212105, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA27TUB6VHMJQNKOWBAGAULRTD3KLANCNFSM4NIDIQNQ .

AlexThurston commented 4 years ago

I've reported this to @jarnold01 through email since he and I were debugging but I thought I'd post it here so that there is some traceability in with the issue.

It looks like the crux of the issue here is with the TLS handshake. It looks as though the current set of cipher suites that is supported by the demo server is:

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

However, my client (which is the Golang TLS implementation) does not advertise any of those.

There are two problems here. The first is that I believe the RFC states that the TLS server should response with the error if a valid ciphersuite cannot be negotiated. Instead, the current implementation is simply dropping the connection which is why I get not feedback as to why the negotiation was unsuccessful.

Secondly, it would appear at thought the RFC does have a mandatory ciphersuite: TLS_RSA_WITH_AES_128_CBC_SHA (https://tools.ietf.org/html/rfc5246#section-9) which isn't supported.

If I look at the support list from the production server, it is reporting support for:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

Which does seems like a more common and appropriate list.

smuellerDD commented 4 years ago

Am Montag, 25. Mai 2020, 16:22:42 CEST schrieb Alex Thurston:

Hi Alex,

Secondly, it would appear at thought the RFC does have a mandatory ciphersuite: TLS_RSA_WITH_AES_128_CBC_SHA (https://tools.ietf.org/html/rfc5246#section-9) which isn't supported.

I think that more and more folks will object to this cipher suite considering that it does not provide perfect forward secrecy.

Ciao Stephan

AlexThurston commented 4 years ago

That's OK. If there is a problem with that ciphersuite then would it be possible to enable one or more of any of these:

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

Or even the same set as production would be helpful. Why not choose some ECDHE ciphersuite?

mwcw commented 4 years ago

Hi, We have lost our ability to authenticate as well. We can establish a TLS session but our password is being refused. I have checked the TOTP generation against the libacvp implementation and we get the same result for a given secret and time.

Let me know if you need any more information.

AlexThurston commented 4 years ago

Check the expiry of your certificate. Mine happens to be expiring soon. Just a thought.

On Mon, May 25, 2020 at 10:07 PM MW notifications@github.com wrote:

Hi, We have lost our ability to authenticate as well. We can establish a TLS session but our password is being refused. I have checked the TOTP generation against the libacvp implementation and we get the same result for a given secret and time.

Let me know if you need any more information.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-633770975, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA27TUDOBM3PI36YYHNSCF3RTMP6NANCNFSM4NIDIQNQ .

mwcw commented 4 years ago

Our certificate expired a couple of years back I enquired about uploading a new request and the old cert started working again on the demo server.

jarnold01 commented 4 years ago

The interesting thing is that there are many more cipher suites listed as available so it's odd to me that only four are actually being advertised. Note that I did have to remove several as a result of a TLS test result that we were presented with from our security group. Anyway, I'll be looking into this shortly; will follow back up.

AlexThurston commented 4 years ago

@jarnold01 Sweet. The list does seem very short and restrictive. I suspected that perhaps it was a configuration issue that was incorrectly reducing the number of ciphersuite.

jarnold01 commented 4 years ago

Okay the cipher suites have been updated, and so anyone who has been having connectivity issues since the web public update, please give it another go and report back that you are confirmed working....or not.

I've personally tested both libacvp and acvpproxy/parser so I know those clients are working as expected, at least from the Linux OS, anyway. MacOS is my real concern/interest with this request as that is the OS that has reported the most problems where the cipher suite issue has been concerned. Thanks.

AlexThurston commented 4 years ago

I can confirm I am able to connect successful. This is via OSX, but through Golang.

smuellerDD commented 4 years ago

Am Dienstag, 26. Mai 2020, 21:10:44 CEST schrieb Alex Thurston:

Hi Alex,

I can confirm I am able to connect successful. This is via OSX, but through Golang.

macOS native TLS and CURL based on OpenSSL works out of the box

Ciao Stephan

locksmithone commented 4 years ago

WSL (Windows Subsystem for Linux) with Ubuntu and OpenSSL 1.1.1 is currently broken. The error is 403 - Forbidden: Access is denied. Here are two tasks performed just before the error using Stephan's acvp-proxy.

ACVPProxy (16:54:37) (vid188544) Status: Logging into ACVP server to refresh existing auth token ACVPProxy (16:54:38) (vid188544) Warning - HTTP operation: Unable to HTTP POST data for URL https://demo.acvts.nist.gov:443/acvp/v1/login: 403

WSL was working fine before the update.

MP

On Tue, May 26, 2020 at 2:16 PM smuellerDD notifications@github.com wrote:

Am Dienstag, 26. Mai 2020, 21:10:44 CEST schrieb Alex Thurston:

Hi Alex,

I can confirm I am able to connect successful. This is via OSX, but through Golang.

macOS native TLS and CURL based on OpenSSL works out of the box

Ciao Stephan

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634223770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDIKQYBXBX23SJPXZMAMLRTQIQVANCNFSM4NIDIQNQ .

AlexThurston commented 4 years ago

I’m going to guess it’s because it’s trying to refresh the existing token rather than make a new one. Delete the cached token so it gets a new one.

This is just a guess.

On Tue, May 26, 2020 at 5:57 PM Marcos Portnoi notifications@github.com wrote:

WSL (Windows Subsystem for Linux) with Ubuntu and OpenSSL 1.1.1 is currently broken. The error is 403 - Forbidden: Access is denied. Here are two tasks performed just before the error using Stephan's acvp-proxy.

ACVPProxy (16:54:37) (vid188544) Status: Logging into ACVP server to refresh existing auth token ACVPProxy (16:54:38) (vid188544) Warning - HTTP operation: Unable to HTTP POST data for URL https://demo.acvts.nist.gov:443/acvp/v1/login: 403

WSL was working fine before the update.

MP

On Tue, May 26, 2020 at 2:16 PM smuellerDD notifications@github.com wrote:

Am Dienstag, 26. Mai 2020, 21:10:44 CEST schrieb Alex Thurston:

Hi Alex,

I can confirm I am able to connect successful. This is via OSX, but through Golang.

macOS native TLS and CURL based on OpenSSL works out of the box

Ciao Stephan

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634223770, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAHDIKQYBXBX23SJPXZMAMLRTQIQVANCNFSM4NIDIQNQ

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634302170, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA27TUA36YLZ2TDINIOGVETRTQ3NNANCNFSM4NIDIQNQ .

locksmithone commented 4 years ago

Just deleted them, but the issue persists.

As somebody mentioned the certificates, I verified that mine expired a while ago, even though it was still working past expiration. Maybe the update is enforcing the expiration. I have requested a new cert to verify whether this is the issue.

MP

On Tue, May 26, 2020 at 4:59 PM Alex Thurston notifications@github.com wrote:

I’m going to guess it’s because it’s trying to refresh the existing token rather than make a new one. Delete the cached token so it gets a new one.

This is just a guess.

On Tue, May 26, 2020 at 5:57 PM Marcos Portnoi notifications@github.com wrote:

WSL (Windows Subsystem for Linux) with Ubuntu and OpenSSL 1.1.1 is currently broken. The error is 403 - Forbidden: Access is denied. Here are two tasks performed just before the error using Stephan's acvp-proxy.

ACVPProxy (16:54:37) (vid188544) Status: Logging into ACVP server to refresh existing auth token ACVPProxy (16:54:38) (vid188544) Warning - HTTP operation: Unable to HTTP POST data for URL https://demo.acvts.nist.gov:443/acvp/v1/login: 403

WSL was working fine before the update.

MP

On Tue, May 26, 2020 at 2:16 PM smuellerDD notifications@github.com wrote:

Am Dienstag, 26. Mai 2020, 21:10:44 CEST schrieb Alex Thurston:

Hi Alex,

I can confirm I am able to connect successful. This is via OSX, but through Golang.

macOS native TLS and CURL based on OpenSSL works out of the box

Ciao Stephan

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634223770, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AAHDIKQYBXBX23SJPXZMAMLRTQIQVANCNFSM4NIDIQNQ

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634302170, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA27TUA36YLZ2TDINIOGVETRTQ3NNANCNFSM4NIDIQNQ

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634302892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDIKVB4XD2VNCYWZEOGATRTQ3UNANCNFSM4NIDIQNQ .

smuellerDD commented 4 years ago

Am Mittwoch, 27. Mai 2020, 00:41:59 CEST schrieb Marcos Portnoi:

Hi Marcos,

Just deleted them, but the issue persists.

As somebody mentioned the certificates, I verified that mine expired a while ago, even though it was still working past expiration. Maybe the update is enforcing the expiration. I have requested a new cert to verify whether this is the issue.

Deleting the old token does not work because you cannot recover the session any more.

For any connectivity issues try with the proxy --cipher-list option (note, you may get an error of not listing the data due to work in the algorithm listing, but you should be able to log in - see -vvv).

MP

On Tue, May 26, 2020 at 4:59 PM Alex Thurston notifications@github.com wrote:

I’m going to guess it’s because it’s trying to refresh the existing token rather than make a new one. Delete the cached token so it gets a new one.

This is just a guess.

On Tue, May 26, 2020 at 5:57 PM Marcos Portnoi notifications@github.com wrote:

WSL (Windows Subsystem for Linux) with Ubuntu and OpenSSL 1.1.1 is currently broken. The error is 403 - Forbidden: Access is denied. Here

are

two tasks performed just before the error using Stephan's acvp-proxy.

ACVPProxy (16:54:37) (vid188544) Status: Logging into ACVP server to refresh existing auth token ACVPProxy (16:54:38) (vid188544) Warning - HTTP operation: Unable to HTTP POST data for URL https://demo.acvts.nist.gov:443/acvp/v1/login: 403

WSL was working fine before the update.

MP

On Tue, May 26, 2020 at 2:16 PM smuellerDD notifications@github.com wrote:

Am Dienstag, 26. Mai 2020, 21:10:44 CEST schrieb Alex Thurston:

Hi Alex,

I can confirm I am able to connect successful. This is via OSX, but

through

Golang.

macOS native TLS and CURL based on OpenSSL works out of the box

Ciao Stephan

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634223770,

or

unsubscribe <

https://github.com/notifications/unsubscribe-auth/AAHDIKQYBXBX23SJPXZMAMLR TQIQVANCNFSM4NIDIQNQ

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634302170,

or

unsubscribe <

https://github.com/notifications/unsubscribe-auth/AA27TUA36YLZ2TDINIOGVETR TQ3NNANCNFSM4NIDIQNQ

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634302892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDIKVB4XD2VNCYWZEOGAT RTQ3UNANCNFSM4NIDIQNQ .

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/usnistgov/ACVP/issues/861#issuecomment-634318648

Ciao Stephan

locksmithone commented 4 years ago

On Wed, May 27, 2020 at 12:55 AM smuellerDD notifications@github.com wrote:

Am Mittwoch, 27. Mai 2020, 00:41:59 CEST schrieb Marcos Portnoi:

Hi Marcos,

Just deleted them, but the issue persists.

As somebody mentioned the certificates, I verified that mine expired a while ago, even though it was still working past expiration. Maybe the update is enforcing the expiration. I have requested a new cert to verify whether this is the issue.

Deleting the old token does not work because you cannot recover the session any more.

I suspected, so I kept a backup. :)

I performed the --cipher-list query later to test the authentication. Per the message below, it does seem that it is the authentication that is failing, yet the TLS connection is successfully established.

For any connectivity issues try with the proxy --cipher-list option (note, you may get an error of not listing the data due to work in the algorithm listing, but you should be able to log in - see -vvv).

MP

On Tue, May 26, 2020 at 4:59 PM Alex Thurston notifications@github.com wrote:

I’m going to guess it’s because it’s trying to refresh the existing token rather than make a new one. Delete the cached token so it gets a new one.

This is just a guess.

On Tue, May 26, 2020 at 5:57 PM Marcos Portnoi < notifications@github.com> wrote:

WSL (Windows Subsystem for Linux) with Ubuntu and OpenSSL 1.1.1 is currently broken. The error is 403 - Forbidden: Access is denied. Here

are

two tasks performed just before the error using Stephan's acvp-proxy.

ACVPProxy (16:54:37) (vid188544) Status: Logging into ACVP server to refresh existing auth token ACVPProxy (16:54:38) (vid188544) Warning - HTTP operation: Unable to HTTP POST data for URL https://demo.acvts.nist.gov:443/acvp/v1/login: 403

WSL was working fine before the update.

MP

On Tue, May 26, 2020 at 2:16 PM smuellerDD <notifications@github.com

wrote:

Am Dienstag, 26. Mai 2020, 21:10:44 CEST schrieb Alex Thurston:

Hi Alex,

I can confirm I am able to connect successful. This is via OSX, but

through

Golang.

macOS native TLS and CURL based on OpenSSL works out of the box

Ciao Stephan

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/usnistgov/ACVP/issues/861#issuecomment-634223770>,

or

unsubscribe <

https://github.com/notifications/unsubscribe-auth/AAHDIKQYBXBX23SJPXZMAMLR TQIQVANCNFSM4NIDIQNQ

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/usnistgov/ACVP/issues/861#issuecomment-634302170 ,

or

unsubscribe <

https://github.com/notifications/unsubscribe-auth/AA27TUA36YLZ2TDINIOGVETR TQ3NNANCNFSM4NIDIQNQ

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634302892, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAHDIKVB4XD2VNCYWZEOGAT RTQ3UNANCNFSM4NIDIQNQ> .

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/usnistgov/ACVP/issues/861#issuecomment-634318648

Ciao Stephan

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634444817, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDIKRYOYIEG6WEHDD6QZDRTSTM5ANCNFSM4NIDIQNQ .

smuellerDD commented 4 years ago

I reported that for macOS the TLS authentication works. I need to correct that statement: it works for macOS 10.15 but not for 10.14.

So, Jason, were you able to understand why your server reject authentication when using some cipher suites? I think we need to get to the bottom of that as otherwise we have cipher suites that are advertised but do not work.

jarnold01 commented 4 years ago

This is the first report of authentication not working on the new web public stack when the TLS handshake has completed - our prior conversations and investigation were all related to the old web platform no longer in use and therefore are not relevant. Clearly the new stack is more stringent in certain aspects.

I don't have a 10.14 box to test with - only 10.15. Do we know which cipher suites 10.14 supports/prefers?

jarnold01 commented 4 years ago

@locksmithone I'm working on generating your renewed cert right now and will be sending it out shortly, so hang tight...

smuellerDD commented 4 years ago

Am Mittwoch, 27. Mai 2020, 18:34:36 CEST schrieb Jason Arnold:

Hi Jason,

This is the first report of authentication not working on the new web public stack when the TLS handshake has completed - our prior conversations and investigation were all related to the old web platform no longer in use and therefore are not relevant. Clearly the new stack is more stringent in certain aspects.

I don't have a 10.14 box to test with - only 10.15. Do we know which cipher suites 10.14 supports/prefers?

Can you please send me the full list of configured and allowed cipher suites? Then I can try enumerate them with curl

Ciao Stephan

jarnold01 commented 4 years ago

Here is a list of the ciphers copied directly from the policy editor for TLS 1.2. I did not include the listed cipher suites for SSL2, SSL3, TLS 1.0 and TLS 1.1 as those are all disabled.

TLS 1.2 SHA256 and SHA384 cipher suites:

TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_NULL_SHA256

TLS 1.2 ECC GCM cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521

locksmithone commented 4 years ago

Tested again with WSL Ubuntu OpenSSL 1.1.1 with newly authentication certificate. Authentication now works and I can interact with the server.

MP

On Wed, May 27, 2020 at 3:00 PM Jason Arnold notifications@github.com wrote:

Here is a list of the ciphers copied directly from the policy editor for TLS 1.2. I did not include the listed cipher suites for SSL2, SSL3, TLS 1.0 and TLS 1.1 as those are all disabled.

TLS 1.2 SHA256 and SHA384 cipher suites:

TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_NULL_SHA256

TLS 1.2 ECC GCM cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/861#issuecomment-634908626, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDIKQGOOCPSHJTU3A2TPDRTVWOHANCNFSM4NIDIQNQ .

jarnold01 commented 4 years ago

@locksmithone Thanks for confirming, Marcos.

smuellerDD commented 4 years ago

Am Mittwoch, 27. Mai 2020, 22:00:35 CEST schrieb Jason Arnold:

Hi Jason,

Here is a list of the ciphers copied directly from the policy editor for TLS 1.2. I did not include the listed cipher suites for SSL2, SSL3, TLS 1.0 and TLS 1.1 as those are all disabled.

TLS 1.2 SHA256 and SHA384 cipher suites:

TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

Those are successful.

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521

Naturally I cannot test those as I do not have an ECDSA cert

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

Naturally I cannot test those as I do not have a DSA cert

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Those are successful.

TLS_RSA_WITH_NULL_SHA256

This is a mistake, right? The TLS connection is refused with it anwyays.

TLS 1.2 ECC GCM cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521

I cannot test those as I do not have an ECDSA cert.

So, I am not sure why macOS 10.14 is giving issues. We try some more on our side too.

Ciao Stephan

jarnold01 commented 4 years ago

TLS_RSA_WITH_NULL_SHA256 This is a mistake, right? The TLS connection is refused with it anwyays.

Not a mistake - Microsoft is including it for whatever reason in their TLS 1.2 policy. It has never shown up on any of the external tests that I've run either, so that's a good thing. Thanks for confirming it is refused for you as well.

So, I am not sure why macOS 10.14 is giving issues. We try some more on our side too.

Okay. Thanks for giving these a run-through and let me know if there's anything else you come across for 10.14. If I come across anything in my research, I'll be sure to note it here.

smuellerDD commented 4 years ago

Am Donnerstag, 28. Mai 2020, 13:40:15 CEST schrieb Jason Arnold:

Hi Jason,

TLS_RSA_WITH_NULL_SHA256 This is a mistake, right? The TLS connection is refused with it anwyays.

Not a mistake - Microsoft is including it for whatever reason in their TLS 1.2 policy. It has never shown up on any of the external tests that I've run either, so that's a good thing. Thanks for confirming it is refused for you as well.

So, I am not sure why macOS 10.14 is giving issues. We try some more on our side too. Okay. Thanks for giving these a run-through and let me know if there's anything else you come across for 10.14. If I come across anything in my research, I'll be sure to note it here.

It seems it is an expired key on our side where the validity of the key is now enforced. We will obtain a new one and confirm.

Ciao Stephan

QuentinGouchet commented 4 years ago

I can confirm Stephan's previous statement. It seems like the server now enforces expired certificate. Obtaining a new certificate fixed the login issue.

jarnold01 commented 4 years ago

I can confirm Stephan's previous statement. It seems like the server now enforces expired certificate. Obtaining a new certificate fixed the login issue.

Great; thanks @QuentinGouchet

Kritner commented 4 years ago

The public rewrite has been released to production. Please let us know if any issues are found, thanks for the help testing everyone!