transport socket: api and implementation for startTls transport socket#13112
transport socket: api and implementation for startTls transport socket#13112mattklein123 merged 37 commits intoenvoyproxy:masterfrom
Conversation
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
mattklein123
left a comment
There was a problem hiding this comment.
Thanks, at a high level this LGTM. This is small enough that I'm not sure it's worth merging as is. Do you want to provide the implementation (even if without tests) and we can review the whole thing together?
/wait
|
Thanks for reviewing. It makes total sense to add socket implementation to this PR. |
|
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
WIP. |
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Consolidated fixture classes. Renamed data members to indicate if they are used by cleartext or tls. Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Changed passthrough_ to oper_socket_. Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
|
Originally this PR contained only api definition. Since then I added starttls socket implementation plus integration test. The integration test simulates the intended usage of the starttls transport socket. A client opens a clear-text connection and as protocol exchange progresses, a filter understanding the protocol may instruct the transport socket to start using tls. Switching from clear-text to tls must happen without closing the socket: tls handshake starts over the same socket where clear-text exchange happened. Testing/coverage should still be expanded, but I believe that there is enough content right now to see if this is going in the right direction. |
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
lizan
left a comment
There was a problem hiding this comment.
Sorry for the delay, in general this is in good structure, starting from high level comments.
| /** | ||
| * @return std::string type of the underlying transport socket. | ||
| */ | ||
| virtual std::string transportProtocol() const PURE; |
There was a problem hiding this comment.
The only meaningful use of this one is to check whether transport socket can startSecureTransport, but I don't think you really need as you can call startSecureTransport and check its return value?
There was a problem hiding this comment.
You are probably right. I was originally thinking that a filter could check underlying transport socket when it receives a configuration and could verify that it sits on top of starttls transport socket. But it has to wait until connection is formed and only then can check if the stack contains starttls transport socket. Therefore, as you suggest, it can just try to call startSecureTransport and complain when it returns false.
There was a problem hiding this comment.
Yeah if you want to reject at configuration level this should be part of transport socket factory but not connection.
| /** | ||
| * @return std::string type of the underlying transport socket. | ||
| */ | ||
| virtual std::string transportProtocol() const PURE; |
There was a problem hiding this comment.
Yeah if you want to reject at configuration level this should be part of transport socket factory but not connection.
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
lizan
left a comment
There was a problem hiding this comment.
LGTM, @mattklein123 can you take a look?
mattklein123
left a comment
There was a problem hiding this comment.
Thanks generally LGTM. Flushing out a few comments. Thank you!
/wait
| // Socket used in all transport socket operations. | ||
| // initially it is set to use raw buffer socket but | ||
| // can be converted to use ssl. | ||
| Network::TransportSocketPtr oper_socket_; |
There was a problem hiding this comment.
nit: I don't know what oper_socket means. Can you name this something a bit better?
There was a problem hiding this comment.
Renamed to active_socket_
I imagined oper_ to mean operating
| if (!using_ssl_) { | ||
| ssl_socket_->setTransportSocketCallbacks(*callbacks_); | ||
| ssl_socket_->onConnected(); | ||
| oper_socket_ = std::move(ssl_socket_); |
There was a problem hiding this comment.
Can transport sockets internally buffer? Is this guaranteed to be correct? Can we drop buffered data if there is flow control?
There was a problem hiding this comment.
I think that in this case we are safe. RawBuffer::doWrite/doRead do not buffer.
In general case, where any type of transport socket could be plugged in, it would be nice to have ::flush() method to call before switching.
There was a problem hiding this comment.
Please add a TODO/comment about this.
| const std::string Tap = "envoy.transport_sockets.tap"; | ||
| const std::string Tls = "envoy.transport_sockets.tls"; | ||
| const std::string UpstreamProxyProtocol = "envoy.transport_sockets.upstream_proxy_protocol"; | ||
| const std::string StartTls = "envoy.transport_sockets.starttls"; |
There was a problem hiding this comment.
We are trying to get rid of these files so just inline the strings where they are needed. Same below.
There was a problem hiding this comment.
What would you say if I leave it as is and create a PR which removes well_known_names.h and inlines strings instead of variables across all files?
… sockets except starttls. Renamed data members to better reflect their meaning. Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
| ":starttls_integration_proto_cc_proto", | ||
| "//source/extensions/filters/network/tcp_proxy:config", | ||
| "//source/extensions/transport_sockets/raw_buffer:config", | ||
| "//source/extensions/transport_sockets/starttls:config", |
There was a problem hiding this comment.
We introduced a new direct dependency between core tests and //source/extensions.
Could we move this test to //test/extensions/transport_sockets ?
There was a problem hiding this comment.
Oops sorry I missed this. Yes @cpakulski please move.
There was a problem hiding this comment.
No problem - will move it.
| IoResult doRead(Buffer::Instance& buffer) override; | ||
| IoResult doWrite(Buffer::Instance& buffer, bool end_stream) override; | ||
| Ssl::ConnectionInfoConstSharedPtr ssl() const override { return nullptr; } | ||
| bool startSecureTransport() override { return false; } |
There was a problem hiding this comment.
Test coverage for this line seems to be flaky. Some runs seem to be hitting it but some aren't.
hit: https://storage.googleapis.com/envoy-pr/2de21bf/coverage/source/common/network/raw_buffer_socket.h.gcov.html
not hit: https://storage.googleapis.com/envoy-pr/48c0687/coverage/source/common/network/raw_buffer_socket.h.gcov.html
There was a problem hiding this comment.
Thanks @antoniovicente. I will investigate it.
Commit Message:
PR defines configuration API and implementation for StartTls transport socket. StartTls is programmable transport socket which starts in clear-text but may programatically be switched to TLS.
Original discussion about use cases is here: #9577
Design document is here: https://docs.google.com/document/d/1ajrQpOEuup04V95xDDY8hSigW4B-J3iuhwn8QQEl-q4/edit?usp=sharing
Risk Level: Low.
Testing: Yes. Added integration tests.
Docs Changes: Some doc sections are automatically produced, but they contain minimum info.
Release Notes: No.