-
Notifications
You must be signed in to change notification settings - Fork 562
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
TLS 1.2 Refactoring #2808
TLS 1.2 Refactoring #2808
Conversation
d9abf34
to
e6bbf61
Compare
In the upstream implementation, concrete implementations of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a first pass over the changes I focussed on the refactoring of the TLS message implementations. Mainly sanity checking the PIMPL-scheme layout. Furthermore, I double-checked the upstream protocol implementation code and the associated relocated _impl_12
classes.
No real surprises, but I'd like to discuss whether we should revert the splitting of the Server_Hello
parsing code into the abstract _Impl
and concrete _Impl_12
classes. I feel it would be better to do those (logic altering) changes in the next step. That said: I didn't find obvious issues with the separation either. @pist-eb, what do you think?
Anyway! Great to see the protocol version abstraction falling into place. 👍
#include <botan/internal/tls_handshake_hash.h> | ||
#include <botan/internal/msg_cert_req_impl.h> | ||
#include <botan/der_enc.h> | ||
#include <botan/ber_dec.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove superfluous includes
RandomNumberGenerator& rng, | ||
const Client_Hello& client_hello, | ||
const Server_Hello::Settings& server_settings, | ||
const std::string next_protocol) : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks different from the upstream Server_Hello
constructor. Note to self: need to look deeper into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this prepares the Server_Hello_Impl
base class for code sharing between 1.2 and 1.3. Frankly, I feel like we should refrain from doing this in this refactoring step and rather do those logic changes with the integration of 1.3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, indeed the _Impl
base classes for messages were prepared to share the common logic of TLS 1.2 and TLS 1.3.
public: | ||
explicit Client_Hello_Impl_13() | ||
{ | ||
// TODO throw std::runtime_error("Implemenation for TLSv1.3 not ready yet. You are welcome to implement it."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not actually throw?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot recall now, but either BoGo_shim was failing with that throw, or one of our custom test scenarios.
Honestly, the border between the 'refactoring of TLS 1.2' and 'implementation of TLS 1.3' was quite thin and maybe we partially started some TLS 1.3 logic changes already during refactoring. Please, feel free to adapt refactored code to your needs and ideas :) |
775610b
to
c11a308
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things look good so far. Still missing tls_channel_impl_12
and tls_client_impl_12
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the final review pass going through the remaining implementation files (mainly channel_impl_12
and client_impl_12
. Unsurprisingly, 99% of these files are just copy & pasted code from the previous (non-pimpl-ed) locations.
This concludes comparing the implementations side-by-side with the respective implementation on the current master
. Cumbersome work, but that also gave me a good overview of the TLS 1.2 implementation code base and the newly added layer of abstraction.
So I went through the refactoring code and compared it to the respective implementations in latest @pist-eb We don't expect you to tackle the nitpicks and comments I attached in the last two weeks. @hrantzsch and I are going to resolve those next week. After that, from our perspective it should be fine to merge this to In any case, |
Please note, that in our refactoring we still had some doubts, whether there are more classes that could be 'protocol version specific' in the end. Unfortunately, we couldn't determine all of them at refactoring phase, probably everything will become clear when implementing TLS 1.3 :) |
Co-authored-by: Marek Kocik <extern.Marek.Kocik@elektrobit.com> Co-authored-by: Grzegorz Dulewicz <extern.Grzegorz.Dulewicz@elektrobit.com> Co-authored-by: Pawel Bazelewski <extern.pawel.bazelewski@elektrobit.com> Co-authored-by: Pawel Jarosz <extern.pawel.jarosz@elektrobit.com>
bf441e8
to
7de394f
Compare
Rebased to latest |
Co-authored-by: René Meusel <rene.meusel@nexenio.com>
7de394f
to
05e7e7c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good for now. I'm sure we'll find many more things while getting our feet wet when implementing TLS 1.3.
The refactoring of the TLS 1.2 code done by @pist-eb and his colleagues in #2806 only. This way we can review and merge into the TLS 1.3 dev branch independently of the added TLS 1.3 code.