-
Notifications
You must be signed in to change notification settings - Fork 51
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
Sporadic EOF while reading (interop with NSS) #58
Labels
Comments
And apparently this is by design... Need to check the returned length rather than error. From
|
Lekensteyn
added a commit
that referenced
this issue
Dec 5, 2017
Similar to boringssl, reuse the NSS client image for the NSS server test against the tris client. Bump the NSS version to 3.34.1 gain support for TLS 1.3 keylogging which is useful while debugging. Adjust read check to fix intermittent NSS test failures: #58
Lekensteyn
added a commit
that referenced
this issue
Dec 13, 2017
Similar to boringssl, reuse the NSS client image for the NSS server test against the tris client. Bump the NSS version to 3.34.1 gain support for TLS 1.3 keylogging which is useful while debugging. Adjust read check to fix intermittent NSS test failures: #58
Fix merged into master, closing. |
Lekensteyn
added a commit
to cloudflare/mitm.watch
that referenced
this issue
Dec 25, 2017
When the server closes the connection after sending data, the response is successful (EOF is not an error if n > 0). Similar issue as cloudflare/tls-tris#58
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After adding NSS to the interop tests for #43, the client test sporadically fail (or sporadically succeed 😉 ). The client (_dev/tris-testclient/client.go) is executed against the NSS test server (_dev/tstclnt/server.sh). For some reason it only happens with the TLS 1.2 test, the three following TLS 1.3 tests have no issue. I have not seen the issue with boringssl before.
While trying to track this down, the following message is visible in the travis logs (the "Failed handshakes" line is out of order due to stdout vs stderr, from this build):
In another build with pcap+keylog enabled (original log: log-005.txt, commit a8d4e4d, branch pwu/travis), it failed in the second run:
In tcp.stream==4 of 005.tar.gz, the server sends application data, close_notify and TCP FIN. The client also sends a close_notify but receives a TCP RST. (In stream 0 where the test passes, the client is earlier with sending its close_notify and FIN/ACK and the server (selfserv) receives a TCP RST instead.)
Restarting this build has these results:
Possibly related issue with the same cause: golang/go#19874
Actually the minimum reproducer seems to be the program below.
Output using upstream go version go1.9.2 darwin/amd64 (most of the time this fails the first handshake, but sometimes it fails the second):
Changing the read buffer size to something smaller (e.g. "1") seems to avoid the issue. Perhaps it should not return EOF when some data is already read (i.e. a partial read).
main.go:
The text was updated successfully, but these errors were encountered: