-
Notifications
You must be signed in to change notification settings - Fork 38
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
Correctly implement close_notify semantic #34
Comments
jerryz920
pushed a commit
to jerryz920/tokio-rustls
that referenced
this issue
Apr 19, 2019
jerryz920
pushed a commit
to jerryz920/tokio-rustls
that referenced
this issue
Apr 19, 2019
jerryz920
pushed a commit
to jerryz920/tokio-rustls
that referenced
this issue
Apr 22, 2019
jerryz920
pushed a commit
to jerryz920/tokio-rustls
that referenced
this issue
Apr 22, 2019
jerryz920
pushed a commit
to jerryz920/tokio-rustls
that referenced
this issue
Apr 22, 2019
quininer
added a commit
that referenced
this issue
Apr 22, 2019
#34 properly implement TLS-1.3 shutdown behavior
oh this can be closed as well ;) |
quininer
pushed a commit
that referenced
this issue
Apr 26, 2024
Avoids taking a dev-dependency on webpki.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I mentioned in #33 that bi-directional copy can lead to an unexpected connection reset. The reason is that the master branch (commit b6e3945) currently sets stream state to SHUTDOWN after the client calls AsyncWrite.shutdown(). This state will make read call to return Ok(0). So the client thoughts EOF came and drops the socket. However, the server still has data to write at the moment, so a connection reset is thrown.
This is a specification problem: TLS 1.2 requires the close_notify to also close read. However, the presence of middle boxes make this behavior inappropriate, and I believe many TLS implementation like OpenSSL actually allows "half-close" semantic.
In TLS 1.3 this should have been changed: https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#closure-alerts. So this means the shutdown state should not affect read any more. Further, EoF should also not affect shutdown. I guess it will make sense to use bit-mask to allow both state to be set or separate the enum to ReadState and WriteState.
thanks
The text was updated successfully, but these errors were encountered: