-
Notifications
You must be signed in to change notification settings - Fork 20
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
Use tls socket to retrieve distinguished name #21
Use tls socket to retrieve distinguished name #21
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.
this looks awesome, and based on what I'd seen before in the TLS implementation it makes sense. I left a few comments / questions.
I guess in redpanda, src/v/net/server.cc - server::accept
after we call accept on the socket we can co_await on the handshake / DN before setting up the final connection and handing it off to the protocol implementation (e.g. kafka).
tests/unit/tls_test.cc
Outdated
auto dn = fdn.get(); | ||
BOOST_REQUIRE(dn.has_value()); | ||
}); | ||
}); | ||
|
||
auto client_socket = tls::connect(cert_creds, addr).get(); | ||
auto client_fin = client_socket.input(); | ||
auto read_buf = client_fin.read_exactly(5).get(); | ||
client_fin.close().get(); |
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.
Can we make this test a bit more sophisticated? Something that tests multiple clients and verifies the contents of the DN? I was thinking something like:
- generate server certs
- generate client1 certs with DN that contains some magic value 1 (e.g. some domain)
- generate client2 certs with DN that contains some magic value 2 (e.g. some other domain)
- start a server that writes the DN on its connection to the connection output
- each client connects, reads the output, verifies that it contains the expected magic value
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.
did that
src/net/tls.cc
Outdated
@@ -1336,7 +1347,7 @@ class session : public enable_lw_shared_from_this<session> { | |||
return make_exception_future<>(std::system_error(ENOTCONN, std::system_category())); | |||
} | |||
if (!_connected) { | |||
return handshake().then([this, p = std::move(p)]() mutable { | |||
return handshake().discard_result().then([this, p = std::move(p)]() mutable { |
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'm not sure I understand why discard_result
is used here. afaict handshake()
already returns a future<>
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.
artefact from previous implementation
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.
removed it
7ecfb52
to
3fac4fb
Compare
Previously, it was possible to get DN using dn_callback passed to credentials object. This callback is invoked on every handshake (if 'client_auth' is set to true) and accepts two parameters, subject and issuer. But there is no way for the user of the tls library to connect particular client connection with the DN string. This commit adds a 'get_distinguished_name' method to connected socket interface. This commit can be used to wait on a future that returns a distinguished name or nullopt after a handshake. The handshake is performed asynchrnously. Because of that the retrieval of the DN string should also be asynchronous. This commit also adds a unit test and scripts that generate a bunch of certificates/keys for it.
3fac4fb
to
8fe5b6e
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.
Zero comments from me, looks great:+1:
Previously, it was possible to get DN using dn_callback passed to
credentials object. This callback is invoked on every handshake (if
'client_auth' is set to true) and accepts two parameters, subject and
issuer. But there is no way for the user of the tls library to connect
particular client connection with the DN string.
This commit adds a 'get_distinguished_name' method to connected socket
interface. This commit can be used to wait on a future that returns a
distinguished name or nullopt after a handshake. The handshake is
performed asynchrnously. Because of that the retrieval of the DN string
should also be asynchronous.
This commit also adds a unit test and scripts that generate a bunch of
certificates/keys for it.