Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

CipherSuitePolicy implementation#36648

Closed
krwq wants to merge 12 commits intodotnet:masterfrom
krwq:ciphersuitespolicy
Closed

CipherSuitePolicy implementation#36648
krwq wants to merge 12 commits intodotnet:masterfrom
krwq:ciphersuitespolicy

Conversation

@krwq
Copy link
Member

@krwq krwq commented Apr 6, 2019

No description provided.

@dotnet dotnet deleted a comment from azure-pipelines bot Apr 6, 2019
@dotnet dotnet deleted a comment from azure-pipelines bot Apr 6, 2019
@@ -0,0 +1,22 @@
// Licensed to the .NET Foundation under one or more agreements.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what the "remove" is for. If it's the file, OK. If it's the license header, no... it should still be around.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant the whole file, initially it was doing a bit more but after couple of iterations it ended up being redundant...

}
// user explicitly asks for TLS 1.3 but their policy is not compatible with TLS 1.3
throw new SslException(
SR.Format(SR.net_ssl_encryptionpolicy_notsupported, policy));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a thing that we might want to change later. If I said, TLS 1.2 or TLS 1.3 and then didn't include any TLS 1.3 ciphersuites then the "TLS 1.2" part of the or still seems to apply, just as if the remote didn't support TLS 1.3, or the TLS 1.3 ciphersuites I did.

That said, if the TLS 1.3 rules are "if both sides support TLS 1.3, but can't agree on a ciphersuite, fail", then maybe this is okay?

Exception now and no-exception-later is the happier path, so this is fine if we can't justify my thought experiment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bartonjs actually this happens when user wants TLS1.3 (protocols include it) but user specified ciphersuites in such a way that TLS1.3 cannot happen (none TLS 1.3 ciphersuites included in a policy) - so user contradicted themselves

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so user contradicted themselves

Yeah, I know. The cases where this would come up seem vanishingly small, but the easy one is trying to build something like SslLabs, where you connect, see what ciphersuite got negotiated, remove it from the allow list, and try again. When the last TLS 1.3 ciphersuite gets removed the next call throws.

The throw just means that we're pushing the knowledge of TLS 1.3 vs prior ciphersuites onto the caller. Which, given we are encouraging people to just use system defaults (after configuring their system, if they don't like the out-of-the-box answer), seems okay for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got mixed feelings for that - if user doesn't want to know about TLS 1.3 they should use None for protocols in which case we won't throw.

Perhaps let's leave as is and perhaps change it when someone complains this is not intuitive?

I don't feel strongly either way - allowing this would simplify a code a bit but feels to me that asking for TLS 1.3 and not passing any ciphers which could allow us to do so is a user bug - for scenarios like SslLabs they will have to understand the cipher suites either way...

@@ -0,0 +1,22 @@
// Licensed to the .NET Foundation under one or more agreements.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what the "remove" is for. If it's the file, OK. If it's the license header, no... it should still be around.

@krwq
Copy link
Member Author

krwq commented Apr 9, 2019

finally green on the CI. Left:

  • apply remaining feedback
  • add tests for AllowedCipherSuites property
  • double check tests for covering corner cases
  • osx implementation

@dotnet dotnet deleted a comment from azure-pipelines bot Apr 10, 2019
@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

/azp run

@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

test this please

@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

/azp help

@azure-pipelines
Copy link

Supported commands
     help:
          Get descriptions, examples and documentation about supported commands
          Example: help "command_name"
     run:
          Run all pipelines or a specific pipeline for this repository using a comment. Use
          this command by itself to trigger all related pipelines, or specify a pipeline
          to run.
          Example: "run" or "run pipeline_name"

See additional documentation.

@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

/azp run corefx-ci

@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

@safern @dotnet/dnceng how do I get this picked up by CI? this has already been running correctly, then it got green and it doesn't get picked up by CI anymore

@safern
Copy link
Member

safern commented Apr 10, 2019

Maybe it is related to it being a draft PR? Can you try closing and reopening?

@krwq krwq closed this Apr 10, 2019
@krwq krwq reopened this Apr 10, 2019
@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

/azp run

@krwq krwq closed this Apr 10, 2019
@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

/azp run

@krwq krwq reopened this Apr 10, 2019
@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

/azp run

@krwq
Copy link
Member Author

krwq commented Apr 10, 2019

@safern probably related, but seems we shouldn't be doing anything special for draft PRs, right? people use them to test stuff on CI, everything else I can do locally without opening any PR

@krwq krwq closed this Apr 10, 2019
@karelz karelz added this to the 3.0 milestone May 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants