Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SslStream.HashAlgorithm does not seems to work with Tls12 and above #37578

Closed
wfurt opened this issue Jun 8, 2020 · 12 comments
Closed

SslStream.HashAlgorithm does not seems to work with Tls12 and above #37578

wfurt opened this issue Jun 8, 2020 · 12 comments

Comments

@wfurt
Copy link
Member

wfurt commented Jun 8, 2020

Description

I used examples from https://docs.microsoft.com/en-us/dotnet/api/system.net.security.sslstream.hashalgorithm?view=net-5.0

static void DisplaySecurityLevel(SslStream stream)
{
   Console.WriteLine("Cipher: {0} strength {1}", stream.CipherAlgorithm, stream.CipherStrength);
   Console.WriteLine("Hash: {0} strength {1}", stream.HashAlgorithm, stream.HashStrength);
   Console.WriteLine("Key exchange: {0} strength {1}", stream.KeyExchangeAlgorithm, stream.KeyExchangeStrength);
   Console.WriteLine("Protocol: {0}", stream.SslProtocol);
}

When I force Tls11 I see TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA negotiated and output of:

Cipher: Aes128 strength 128
Hash: Sha1 strength 160
Key exchange: DiffieHellman strength 0
Protocol: Tls11

when I use default, Tls12 or Tls13 I get TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and :

Cipher: Aes128 strength 128
Hash: None strength 0
Key exchange: DiffieHellman strength 0
Protocol: Tls12

Configuration

Tested with current 5.0 version on Linux with OpenSsl 1.1.1 and macOS 10.15 Catalina.

Other information

We seems to have no unit test to cover HashAlgorithm.

@ghost
Copy link

ghost commented Jun 8, 2020

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Jun 8, 2020
@karelz karelz added this to the Future milestone Jun 18, 2020
@karelz karelz removed the untriaged New issue has not been triaged by the area owner label Jun 18, 2020
@karelz
Copy link
Member

karelz commented Jun 18, 2020

Triage: Not critical for 5.0. @wfurt plans to do a write up and follow up with crypto to decide what to do here.

@wfurt
Copy link
Member Author

wfurt commented Jul 8, 2020

This seems to be by design. The SHA256 from the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is ignored and it boils down to GCM from AES. In that mode AES is able to perform integrity using AEAD.
However, returning null is really not that helpful IMHO. I'm wondering if we could either return "AES" or "AEAD" or some better hint to what is going on.

cc: @bartonjs

@bartonjs
Copy link
Member

bartonjs commented Jul 8, 2020

Classically, the return value here is dictated by whatever SChannel reports, then just making the OpenSSL/macOS PALs try to report the same thing for the same ciphersuites.

@wfurt
Copy link
Member Author

wfurt commented Jul 9, 2020

That does not quite match the windows. I did test run and I get:

  Cipher: Aes256 strength 256
  Hash: Sha384 strength 0
  Key exchange: 44550 strength 384
  Protocol: Tls12
  Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

interestingly, hash strength is 0, and we don't seems to map properly the KeyExchange algorithm.

@krwq
Copy link
Member

krwq commented Aug 4, 2020

@wfurt
Copy link
Member Author

wfurt commented Aug 4, 2020

It is interesting that it does not match Windows behavior as @bartonjs expected.
Using something else then null may be still useful. Or perhaps add explicit note to docs about AEAD.

@krwq
Copy link
Member

krwq commented Aug 4, 2020

I believe Windows answer is wrong in that case (assuming by HashAlgorithm we mean MAC and that's what docs describe).

For reporting issue I'd reccomend to change Windows to use https://github.com/dotnet/runtime/blob/master/src/libraries/System.Net.Security/src/System/Net/Security/TlsCipherSuiteData.Lookup.cs instead of answer returned by SChannel which returns hash used for HKDF

And then to improve reporting I'd recommend to do one of the following:

@rzikm rzikm self-assigned this Mar 9, 2022
@rzikm
Copy link
Member

rzikm commented Mar 16, 2022

As krwq said, HashAlgorithm refers to the MAC algorithm, since the relevant cipher uses AEAD, then HashAlgorithm None of strength 0 makes sense.

For consistency, we might want to use the TlsCipherSuiteData Lookup on Windows as well to decode the key exchange algorithm correctly. I can put up a PR

@wfurt
Copy link
Member Author

wfurt commented Nov 16, 2022

triage: We should resurrect #66702 when #55570 is done. All related, will try for 8.0.

@wfurt wfurt modified the milestones: Future, 8.0.0 Nov 16, 2022
@wfurt wfurt modified the milestones: 8.0.0, Future Jun 6, 2023
@karelz karelz modified the milestones: Future, 9.0.0 Jul 18, 2023
@rzikm
Copy link
Member

rzikm commented Oct 24, 2023

Triage: should be consolidated with the effort on other HashAlgorithmType and other enums.

Potential idea?: Mark everything except TlsCipherSuite obsolete since the cipher suite contains all necessary information, or improve documentation to manage user expectations.

@rzikm rzikm self-assigned this Apr 15, 2024
@rzikm rzikm modified the milestones: 9.0.0, 10.0.0 Jun 26, 2024
@rzikm
Copy link
Member

rzikm commented Aug 14, 2024

Since #100361, the plan is to obsolete the enum, closing as won't do.

@rzikm rzikm closed this as not planned Won't fix, can't repro, duplicate, stale Aug 14, 2024
@rzikm rzikm removed their assignment Aug 14, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Sep 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants