Enhancements #107
Merged
Enhancements #107
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The string is the same as the git version information, so could be '0.20.local-20180223-163246'. Fixes #44
In phase 1, we have defaults set to disabling requirements for Post Quantum cipher suites. One day, the default can migrate. Administrators already get an opportunity to override, but are STRONGLY SUGGESTED to never switch it off; however, it is now possible to experiment with actively switching on support. In lieu of cipher suites, this will fail. So, leave the lines for Post Quantum cipher suites commented as they are in the example configuration file. Part 1/2 involves configuration file settings; part 2/2 involves flags for the validation expression language.
In phase 1, we have defaults set to disabling requirements for Post Quantum cipher suites. Part 2/2 adds flags `Q` and `q` to the validation expression language. These flags currently fail on all accounts, but can still be used in an OR compisition, with alternatives that you would like to remove later. In other words, the TLS Pool allows you to get started with Quantum Proofing today. If the cipher suites that fall under your other options get in disgrace in the future, you may find that your validation expressions silently fall back to these extra OR options. Note that TLS-KDH is a Post Quantum cipher suite. When we finally have our own unique code for this cipher suite, we can implement tis positive results for both the `Q` and `q` flags.
Adriaan implemented it and kept it quit :) but thanks dude! Merge branch 'add-version' of https://github.com/adriaandegroot/tlspool into enhancements
Added runterminal-libev.c and an option EXPERIMENTAL_LIBEV to experiment with libev support. This may be helpful with ports to Windows -- and it may in general be a better idea than crafting these details ourselves -- over and over.
We still have one choice, but GnuTLS is so slow in adopting
TLS-KDH that we are considering to switch to another stack.
The world needs TLS-KDH, for numerous reasons:
- it is protected from Quantum Computing attacks
- that includes encryption
- it is tens of thousands of times more efficient than X.509
- with KXOVER coming up, it can span the globe [0]
[0] though KXOVER is not yet protected from Quantum Computing,
but not everybody needs it; most people don't at this time.
Added a document, doc/message-flow.md, along with a state diagram in doc/std-tlspool-starttls.* that describes what applications usually do to work with the TLS Pool.
This is the "design" of the commands for info check/query. It includes a new command code, with a set of values for kinds of information and a simple protocol to claims, queries, checks.
Implemented the most important variant, tls-unique. GnuTLS does not support the other one in RFC 5929, namely tls-server-end-point, but we might infer that ourselves -- it is merely a certificate hash. It is also less interesting as it cannot distinguish TLS sesssions, so we will sit and wait if this is indeed required by anyone. This closes issue #69. Two test runs report the same information on both ends, but different among sessions. With the tls-server-end-point, the two test runs would yield the same outcome. This is why we are not keen on carrying the weaker form. 1. tlspool-test-client: Channel binding info, tls-unique, 12 bytes of 12: 1c 47 7f 50 84 e5 85 c3 50 24 71 06 tlspool-test-server: Channel binding info, tls-unique, 12 bytes of 12: 1c 47 7f 50 84 e5 85 c3 50 24 71 06 2. tlspool-test-client: Channel binding info, tls-unique, 12 bytes of 12: 18 49 6d a4 b8 c3 fc db 14 9a ba 4b tlspool-test-server: Channel binding info, tls-unique, 12 bytes of 12: 18 49 6d a4 b8 c3 fc db 14 9a ba 4b
Info Query support for the DN in Subject and Issuer fields. Renumbered PIOK_INFO_ codes (while on a development branch, not master) because the initial idea to support Subject/Issuer Unique Identities was squashed by the lyrics in RFC 5280, see the issue ticket.
Info Query support for SubjectAltName values; these match exactly against a GeneralName, for which the certificate will be iterated. Any entry that matches is considered valid, because each statement of identity of this kinds stands on its own.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
876cdfb issue #100, part 2/2, name checking
f8a2c37 issue #100, part 1/2, name checking
7b5afe0 issue #69, channel binding support
6118248 issue #69, initial design of commands
5a0699a issue #99, state diagram for applications
b3310d8 issue #104, infra for STARTTLS_DRIVER selection
b40a4d6 issue #102, libev for runterminal
bf6b007 issue #44, show version number
864d65d issue #85, prepare for Quantum Computing, part 2/2, phase 1
14c9a66 issue #85, prepare for Quantum Computing, part 1/2, phase 1
e9f83a8 Add a -V flag, which prints the TLSPool version string.