-
Notifications
You must be signed in to change notification settings - Fork 37
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
TLS connections aborting #40
Comments
@borrrden commented:
|
... and having filed this here, I realize it's actually a LiteCore issue. Oh well, let's leave it here for now since that's where it manifests. |
Thank you @snej.
and have the following simple driver code (it makes no difference if I use the c++ wrapper):
Running the above gives me
and the Sync Gateway terminal shows
Could you please tell me if you can spot anything wrong with the code above. I believe the server/sync gateway/credentials are set up correctly: I can replicate/read the DB contents with username/password using a similar driver program but running an older version of Litecore API. Also if I remove the authentication requirements on the SG sync function and remove the username/password on the C++ code it works fine. Thanks again. |
I've fixed the HTTP auth issue on the |
Note to self: I've been lazy and only testing with SG on localhost. Need to set it up elsewhere and test with that. |
Thank you very much. I'll give it a try and report back. I'll come back with more info about the TLS connections and the compiling troubles I had on Windows. Also, something could be wrong with the LiteCore submodule tagged on the dev branch, commit 0b1681492eda4378305daeaf94853bbe389b52e4 is showing as a 404 for me. Edit: commit no longer showing as 404. |
Updated LiteCore to pick up the fix. Fixes #40
The bug showed up immediately once I set up SG on an iMac in the next room and ran the TLS unit tests. It was a LiteCore issue: the BuiltinWebSocket class was misinterpreting a zero-byte read as an error, when it just means TLS wasn't able to decode any bytes from the ciphertext it just read. After I fixed it to just ignore the 0-byte read, everything appears to work fine. Fix is on the |
Thank you very much @snej. Just tried out the dev branch and everything worked well, no problems at all for me on Mac anymore. Is there still active development going on for LiteC for Windows? I'm still having the issues on the Windows side that I mentioned on the original thread on the CB forum. These are also all related to DB replication / TLS connections (the last of them was an issue with certificates). To me, the issues on Windows also look like small issues with some newer socket/network code. I've tested both the dev branch and the fix/ci_windows_etc branch, which seems to have several fixes but hasn't been touched since December (there's also an older PR). |
Development is not abandoned, but is subject to constraints on time as it is not an officially supported platform (yet), so supported platforms take priority. I know that's a lame answer, so sorry about that. |
Thank you for the reply @borrrden @snej. I did this by:
was correct. I found a (slightly hacky) way to convert each certificate from DER to PEM format before concatenating to the string stream, and that fixed the problem. All worked fine from then on. I certainly understand the development constraints. Do you have a timeline for finishing/integrating this into dev/master? I'd be glad to make a PR for this since I have the fixes - but I'm not quite sure what the best way of fixing the issue with the certificate format is. Thanks again! |
Thanks, Victor! I'd love to get a PR with that fix, even if it's only a temporary workaround. |
The first step for this is ready: I found a clean solution for the certificate format issue and opened a PR on the sockpp repository. |
Reported by victorberger on the forum:
Specific channel:
The text was updated successfully, but these errors were encountered: