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

SSL refreshes #17

Closed
The-EDev opened this issue Oct 18, 2020 · 3 comments · Fixed by #23
Closed

SSL refreshes #17

The-EDev opened this issue Oct 18, 2020 · 3 comments · Fixed by #23
Assignees
Labels
bug Something isn't working
Milestone

Comments

@The-EDev
Copy link
Member

The-EDev commented Oct 18, 2020

ipkn#319, ipkn#269

I've run into this problem myself (while testing SSL file transfer), although it doesn't happen all the time, and seems to happen randomly for me.

ipkn#347 is a possible fix
Edit: While i do believe the PR above is useful, it does not fix the SSL refresh issue, more research needed.

@The-EDev The-EDev added the bug Something isn't working label Oct 18, 2020
@The-EDev
Copy link
Member Author

Update: testing with a simple hello world route, issue consistently occurs 5 seconds after the last request (5 seconds is the default timeout time)

@The-EDev
Copy link
Member Author

The-EDev commented Oct 20, 2020

ipkn#347 seems to cause an infinite loop.

normal test: run firefox and insomnia rest, call crow from firefox, wait 5+ secs, call again, get SSL_ERROR_INTERNAL_ERROR_ALERT, call from insomnia, wait 5+ secs, call again, works as expected, no errors.

PR 347 test: exact same except app goes into infinite loop 5 secs after insomnia call.

The problem could be due to me shutting down the stream and socket unlike the PR : Edit: Testing shows it is because I shut down SSL, although fixing that the original problem persists.

It's worth mentioning that all of this can be avoided by just running crow behind a proxy like Nginx, but that would be running away from the problem.

@The-EDev The-EDev self-assigned this Oct 20, 2020
@The-EDev
Copy link
Member Author

Ok so building on the answer in ipkn#269, I was able to fix the bug by setting the verify mode to verify_client_once, this is a compromise from the suggested verify_none, although I have not researched the security implications, especially on websockets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant