Support renegotiation-based client auth. #111
Conversation
Motivation: While TLS renegotiation is in general a bad idea, it is widely used for delayed TLS-based client authentication. We are able to support this use-case, and so we should enable it. As with BoringSSL, we'd like to continue to default to not supporting this mode of operation. However, users are free to enable support if they so choose. Modifications: - Added flags for configuring renegotiation. - Added integration test harness. - Added renegotiation integration test with s_server. - Added renegotiation and client cert support to sample client. Result: Users will be able to perform TLS renegotiation.
|
@weissi A note, we probably need to remember to actually run the integration tests. |
| /// Renegotiation is only supported in TLS 1.2 and earlier, and generally does not work very well. NIOSSL will | ||
| /// disallow most uses of renegotiation: the only supported use-case is to perform post-connection authentication | ||
| /// *as a client*. There is no way to initiate a TLS renegotiation in NIOSSL. | ||
| public enum NIORenegotiationSupport { |
There was a problem hiding this comment.
suggestions: Couldn't we nest this type in TLSConfiguration so ie would be TLSConfiguration.RenegotiationSupport? Then it doesn't need the NIO prefix either
There was a problem hiding this comment.
The only reason I put the type here was to keep it in line with the other types used by TLSConfiguration, which are at the top level. If you think that consistency is less important than the convenience of nesting the type, I'm more than happy to move it: I don't really care either way.
There was a problem hiding this comment.
@Lukasa I really don't mind either. Your call!
There was a problem hiding this comment.
Let's leave it where it is: status quo trumps convenience when it comes to the number of types we're discussing. I'll file an issue to move them all into the TLSConfiguration struct for v3.
Motivation: renegiotion is not supported by BoringSSL by default but sometimes when using on the client-side you might want to support it for CLIENT-AUTH. See also apple/swift-nio-ssl#111 Modifications: Add native / java code to be able to enable support Result: Part of netty/netty#11529
Motivation: renegiotion is not supported by BoringSSL by default but sometimes when using on the client-side you might want to support it for CLIENT-AUTH. See also apple/swift-nio-ssl#111 Modifications: Add native / java code to be able to enable support Result: Part of netty/netty#11529
Motivation:
While TLS renegotiation is in general a bad idea, it is widely used for
delayed TLS-based client authentication. We are able to support this
use-case, and so we should enable it.
As with BoringSSL, we'd like to continue to default to not supporting
this mode of operation. However, users are free to enable support if
they so choose.
Modifications:
Result:
Users will be able to perform TLS renegotiation.
Resolves #110