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

using ciphersuite_strong for tests. #216

Merged
merged 8 commits into from
Apr 27, 2017

Conversation

kazu-yamamoto
Copy link
Collaborator

Since ECDHE would be an only common cipher, client/server groups
should always have a common group.

prop_handshake_initiate_tls12 is removed since no common hash-signature
does not always cause a handshake error. Rather, supportedHashSignatures
is specified with available hash-signatures shuffled.

@ocheron
Copy link
Contributor

ocheron commented Apr 22, 2017

What is your goal here?
What I see most is that this decreases test coverage.

@kazu-yamamoto
Copy link
Collaborator Author

The purpose is to use ciphersuite_strong to:

  • enlarge the coverage of cipher suite
  • support testing of TLS 1.3 naturally.

The current test only covers 5 cipher suites. I don't mind if ciphersuite_default is used instead of ciphersuite_strong.

If the test for handshake failures should be kept, I would like to cover no common ciphersuite and groups in addition to no common hash-signatures.

@ocheron
Copy link
Contributor

ocheron commented Apr 24, 2017

Extending is good, but at the same time we should keep tests with non-DH ciphers, with MD5, RC4, etc.

Yes I think we must test both successes and failures.
It is not possible/desirable to test every handshake variation in a single test case.
So in addition to a main test case focused on TLS versions and the default parameters, we should create many test cases so that we test each feature or parameter independently: supported hash/signatures, supported groups, client/server hooks, custom ciphers, etc.

@kazu-yamamoto
Copy link
Collaborator Author

Extending is good, but at the same time we should keep tests with non-DH ciphers, with MD5, RC4, etc.

I agree and done.

@kazu-yamamoto
Copy link
Collaborator Author

Yes I think we must test both successes and failures.
It is not possible/desirable to test every handshake variation in a single test case.
So in addition to a main test case focused on TLS versions and the default parameters, we should > create many test cases so that we test each feature or parameter independently: supported hash/signatures, supported groups, client/server hooks, custom ciphers, etc.

I added test cases which I hit upon. Please review this PR again.

@kazu-yamamoto
Copy link
Collaborator Author

push -f to resolve the conflict.

Copy link
Contributor

@ocheron ocheron left a comment

Choose a reason for hiding this comment

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

That's a good step forward.

) where

import Test.Tasty.QuickCheck
import Certificate
import PubKey
import PipeChan
import Network.TLS
import Network.TLS as TLS
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably not needed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is necessary for HashSHA512 etc.

Since ECDHE would be an only common cipher, client/server groups
should always have a common group.

prop_handshake_initiate_tls12 is removed since no common hash-signature
does not always cause a handshake error. Rather, supportedHashSignatures
is specified with available hash-signatures shuffled.
Probably, the client side should also set SNI if the server returns
an empty SNI and this test case should check it in the client side.
kazu-yamamoto added a commit to kazu-yamamoto/hs-tls that referenced this pull request Apr 27, 2017
@kazu-yamamoto kazu-yamamoto merged commit 0b4b1f2 into haskell-tls:master Apr 27, 2017
@kazu-yamamoto kazu-yamamoto deleted the test-ciphers branch April 27, 2017 01:08
@kazu-yamamoto
Copy link
Collaborator Author

Merged.
Thank you for reviewing!

ocheron added a commit that referenced this pull request May 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants