-
Notifications
You must be signed in to change notification settings - Fork 81
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
Add signature_algorithms_cert extension to _serverTLS13Handshake #513
base: master
Are you sure you want to change the base?
Conversation
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.
Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @Odinmylord)
-- commits
line 2 at r1:
The point of the change is to include signature_algorithms_cert
extension in the CertificateRequest
, isn't it?
tlslite/handshakesettings.py
line 400 at r1 (raw file):
self.record_size_limit = 2**14 + 1 # TLS 1.3 includes content type # data needed for the signature algorithms cert extension self.more_sig_schemes_cert = []
they should have non empty default values; whether those should be the same as the ones for rsa, ecdsa, and other, or not is a separate question
tlslite/handshakesettings.py
line 401 at r1 (raw file):
# data needed for the signature algorithms cert extension self.more_sig_schemes_cert = [] self.ecdsaSigHashesCert = []
camelCase is deprecated, it exists because I don't want to break API, new fields should use snake_case
tlslite/handshakesettings.py
line 685 at r1 (raw file):
other.more_sig_schemes_cert = self.more_sig_schemes_cert other.ecdsaSigHashesCert = self.ecdsaSigHashesCert other.rsaSigHashesCert = self.rsaSigHashesCert
the values need to be validated too
tlslite/tlsconnection.py
line 2835 at r1 (raw file):
cr_settings.more_sig_schemes = cr_settings.more_sig_schemes_cert cr_settings.ecdsaSigHashes = cr_settings.ecdsaSigHashesCert cr_settings.rsaSigHashes = cr_settings.rsaSigHashesCert
we definitely don't want to overwrite those values, settings object can be reused connection to connection
(I'm assuming you want to be able to send different contents in the _cert and non cert extensions, so I've reviewed the PR as such, if that's not your intention, and you're fine with just duplicating values between them, then we don't need changes around handshake settings) |
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.
The idea is to have different values since if there is the same values, according to RFC8446, the signature_algorithms_cert extension can be omitted. Sorry for not being clear enough
Reviewable status: 0 of 2 files reviewed, 5 unresolved discussions (waiting on @tomato42)
Previously, tomato42 (Hubert Kario) wrote…
The point of the change is to include
signature_algorithms_cert
extension in theCertificateRequest
, isn't it?
Yeah, I could have been more clear, sorry
tlslite/handshakesettings.py
line 400 at r1 (raw file):
Previously, tomato42 (Hubert Kario) wrote…
they should have non empty default values; whether those should be the same as the ones for rsa, ecdsa, and other, or not is a separate question
Done. I put the same values as the "standard" extension since if the signature_algorithms_cert extension is not present the signature_algorithms extension is considered. I also updated the condition to not add the signature_algorithms_cert extension if it has the same values as signature_algorithms.
tlslite/handshakesettings.py
line 401 at r1 (raw file):
Previously, tomato42 (Hubert Kario) wrote…
camelCase is deprecated, it exists because I don't want to break API, new fields should use snake_case
Done.
tlslite/handshakesettings.py
line 685 at r1 (raw file):
Previously, tomato42 (Hubert Kario) wrote…
the values need to be validated too
I'm not sure I understand what you mean, isn't the validation performed by the _sigHashesToList function?
tlslite/tlsconnection.py
line 2835 at r1 (raw file):
Previously, tomato42 (Hubert Kario) wrote…
we definitely don't want to overwrite those values, settings object can be reused connection to connection
Done, also updated the _sigHashesToList function accordingly
CI failure are relevant |
tlslite/tlsconnection.py
Outdated
and privateKey and privateKey.n < 2**2047: | ||
continue | ||
# advertise support for both rsaEncryption and RSA-PSS OID | ||
# key type | ||
if certType != 'rsa-pss': | ||
sigAlgs.append(getattr(SignatureScheme, | ||
"rsa_{0}_rsae_{1}" | ||
.format(schemeName, hashName))) | ||
.format(scheme_name, hash_name))) |
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.
Line too long (84 > 79 characters)
tlslite/tlsconnection.py
Outdated
if certType != 'rsa': | ||
sigAlgs.append(getattr(SignatureScheme, | ||
"rsa_{0}_pss_{1}" | ||
.format(schemeName, hashName))) | ||
.format(scheme_name, hash_name))) |
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.
Line too long (84 > 79 characters)
At the moment the _serverTLS13Handshake function does not have a simple way to generate and send the
signature_algorithms_cert
extension. Since the extension is not generated by OpenSSL, tlslite-ng is the easiest way I found to create a webserver that sends this extensionThis change is