Skip to content
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

Nothing gets logged on failed SSL connection #2271

Open
Tronic opened this issue Oct 15, 2021 · 3 comments
Open

Nothing gets logged on failed SSL connection #2271

Tronic opened this issue Oct 15, 2021 · 3 comments

Comments

@Tronic
Copy link
Member

Tronic commented Oct 15, 2021

Even in debug mode nothing at all appears on log when the TLS handshake fails. Connections with no request are only logged if they finish the TLS handshake and then request nothing.

@Tronic
Copy link
Member Author

Tronic commented Oct 15, 2021

If anyone investigates this, could you also check whether we can in that situation do a cleaner TLS shutdown? I believe the client cannot currently receive the proper alert code because Sanic immediately closes the socket.

One way to test is running #2270 and contacting it e.g. by IP address for which there is no cert. The browser should display ERR_SSL_UNRECONIZED_NAME_ALERT on the error page it gives.

@Tronic
Copy link
Member Author

Tronic commented Oct 16, 2021

I have looked into this, and it would appear to be a limitation of both asyncio and uvloop Protocol/Transport API. Using a bare SSLSocket I get the proper response on client side, and can also detect and log any handshake errors, but the Protocol API offers nothing to control this behaviour.

Our protocol object gets constructed as soon as a connection is made (i.e. before handshake) but in the constructor we get no access to transport, socket, etc. that could be used for finding the client IP and other relevant details. If the handshake fails, connection_made never gets called, and apparently there is no other hook that could be used to handle this. As a minor workaround, the sni_callback can log when it aborts a handshake but it does not have access to client IP either. Any other handshake problems could only be logged via protocol's __del__ function and I really don't want to go there.

Leaving the bug open for discussion, and in case anyone figures out a workaround.

@stale
Copy link

stale bot commented Mar 2, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions.

@stale stale bot added the stale label Mar 2, 2022
@stale stale bot removed the stale label Mar 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants