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

HTTPS connection doesn't work with self signed certificate #24

Closed
semmmmml opened this issue Mar 17, 2017 · 13 comments
Closed

HTTPS connection doesn't work with self signed certificate #24

semmmmml opened this issue Mar 17, 2017 · 13 comments

Comments

@semmmmml
Copy link

I copied the API key from the browser and hit test but nothing happens. The test button stays red. I have set a username and password for the GUI but have already tried removing them to see if this solves the problem but it does not. Do I have to enable some settings for the connection to work?

@xor-gate
Copy link
Member

xor-gate commented Mar 17, 2017

Is the URL correct to the syncthing instance? No when a syncthing instance is running it should work. The GUI (user/pass) is separate from the API key. You are the first one which is reporting this. Approximate already 1k downloads. I'm not sure what is happening.

@semmmmml
Copy link
Author

I know, i read all the closed issues before posting in order not to post a stupid question. The URL is correct (I'm using https though but also tried switching it off). I have no idea what is wrong because nothing is happening when i hit test. Is there a way to get feedback from the program in that case? (FYI: I am using MacOS 10.12.3)

@xor-gate
Copy link
Member

Probably https is the problem because the syncthing self signed certificate is not in the certificate pool of OS X and is not trusted. You should try http and see what happens.

@semmmmml
Copy link
Author

Yes, https was the problem! Thanks!

@xor-gate xor-gate changed the title Syncthing Preferences: connection not working HTTPS connection doesn't work with self signed certificate Mar 17, 2017
@xor-gate xor-gate reopened this Mar 17, 2017
@xor-gate
Copy link
Member

xor-gate commented Mar 17, 2017

If have renamed the title of the issue and reopened. This should be fixed, at least an error message should be printed to the user! Thanks for reporting.

@erlandh
Copy link

erlandh commented Jun 25, 2017

Just confirming I had this issue too. Couldn't work out what was wrong until I found this thread. Would be great to have this fixed - ideally to work with https if possible, not just an error message.

I could offer a small amount on Bountysource to see this implemented. Would that be the best way to encourage a fix? :-)

@xor-gate xor-gate added this to the Next milestone Aug 3, 2017
@xor-gate
Copy link
Member

xor-gate commented Apr 17, 2018

I'm dusting of this issue, could you verify if it is fixed with latest release? It seems it works now according to https://forum.syncthing.net/t/syncthing-for-macos/2745/14

@johnantoni
Copy link

tried today, still seems to be an issue with https. the "test api" in the menubar control fails when https is enabled. ok when switched back to http.

@xor-gate
Copy link
Member

For @virusman and me as a reference about TLS in Objective-C https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/NetworkingTopics/Articles/OverridingSSLChainValidationCorrectly.html.

@johnantoni
Copy link

Awesome, not a blocker for me. Can use http for the moment. my little cloud boxes are locked down with https. only use this on my laptop to sync.

@xor-gate
Copy link
Member

xor-gate commented May 19, 2018

I think if you place a reverse HTTP proxy webserver (caddy, nginx) with a lets encrypt certificate in front of http it should work. Because the lets encrypt CA is trusted by OS X. This is theoritical but untested.

@xor-gate xor-gate modified the milestones: v0.14.47-1, Next, Unplanned (contributions welcome) Jun 4, 2018
@calmh
Copy link
Member

calmh commented Jul 28, 2018

I started fixing this as part of fixing #65, and ended up replacing the (deprecated) NSURLConnection stuff with NSURLSession instead. I then noticed (because this is my first few minutes in the code) that the event listening code is only half the API stuff, there is also corresponding in XGSyncthing. Given that the TLS handling here requires implementing a delegate to do the certificate handling etc it would be nice to do it just once.

Would it make sense to move the event subscription stuff into XGSyncthing and do it all there? Or is there a good reason that's not how it is currently?

@xor-gate
Copy link
Member

XGSyncthing should be moved back as STClient or something like that. I had an idea to create a Objective-C library to talk to syncthing, thats why it is not prefixed with ST. Indeed the event stuff which talks to the API needs to be in a central place.

calmh added a commit to calmh/syncthing-macos that referenced this issue Jul 28, 2018
This moves event getting into the XGSyncthing library, while also
refactoring it to use NSURLSession, a delegate for allowing local TLS
certificates, and proper parameters.

The delegate simply skips HTTPS certificate checking on hosts called
"localhost", "127.0.0.1", or "::1". I think this is what most people
would want from this tool.
calmh added a commit to calmh/syncthing-macos that referenced this issue Jul 28, 2018
This moves event getting into the XGSyncthing library, while also
refactoring it to use NSURLSession, a delegate for allowing local TLS
certificates, and proper parameters.

The delegate simply skips HTTPS certificate checking on hosts called
"localhost", "127.0.0.1", or "::1". I think this is what most people
would want from this tool.
calmh added a commit to calmh/syncthing-macos that referenced this issue Jul 28, 2018
@calmh calmh closed this as completed in 0eb0293 Jul 28, 2018
calmh added a commit that referenced this issue Jul 28, 2018
xor-gate added a commit that referenced this issue Nov 7, 2018
* syncthing/Scripts/syncthing-resource.sh: Bundle with 0.14.47

* Get rid of syncthing/Scripts/syncthing-inotify-resource.sh as filesystem change notifications are builtin to syncthing since v0.14.47

* Delay reconnect attempts if the server returned an error (#47)

This should fix high CPU usage issue when API key is invalid. Partial fixes #46.

* Bump syncthing resource to v0.14.48 (#55)

* syncthing/STApplication.m: Sort folders submenu ascending (fixes #49) (#53)

* syncthing/STApplication.m: Sort folders submenu ascending (fixes #49)
* syncthing/STApplication.m: Fix review comment of @virusman

* Use CocoaPods for Sparkle framework dependency (fixes #57) (#60)

* Update syncthing resource to v0.14.49 (#64)

* Update syncthing resource to v0.14.49
* syncthing/Scripts/syncthing-resource.sh: Use new tarball name

* Adjust event request timeout (fixes #65) (#66)

This sets the event request a bit longer and, more importantly, informs
Syncthing of the timeout. The result is that the request returns
successfully without events, and we don't get a timeout error.

* Refactor HTTP(S) handling (fixes #24)

This moves event getting into the XGSyncthing library, while also
refactoring it to use NSURLSession, a delegate for allowing local TLS
certificates, and proper parameters.

The delegate simply skips HTTPS certificate checking on hosts called
"localhost", "127.0.0.1", or "::1". I think this is what most people
would want from this tool.

* Remove #24 from README too

* README.md: Update to use new URLs (#67)

Also add @calmh to AUTHORS.md

* Move LocalhostTLSDelegate files accidentally committed at root (#70)

* Generate appcast.xml from github releases (#63)

* script/ghreleases2appcast.go: Initial working github releases to sparkle framework appcast.xml converter (resolves #62)

* Activate existing windows for About/Preferences (fixes #72) (#73)

* Add daemon process handling (fixes #48) (#71)

* Add new submenu with status of the syncthing service
* Cleanup some code

* Copy executable from bundle (fixes #37) (#76)

This copies the bundled executable before executing it, if the target
executable doesn't already exist. This has several desirable properties:

- We do not mess up the application bundle by letting Syncthing upgrade

- The user can revert an undesired upgrade by deleting the binary and
  restarting the wrapper.

The binary is stored in ~/Application Support/Syncthing-macOS because I
don't want to put it in Syncthing's config directory. That directory is
in principle managed by Syncthing and we can't be sure it won't be
removed or something.

* Prepare for v0.14.49-1 release (#75)

* syncthing.xcodeproj/project.pbxproj: Rename PRODUCT_BUNDLE_IDENTIFIER for Sparkle updater (see #74) (#79)

From com.github.syncthing.syncthing-macos back to com.github.xor-gate.syncthing-macosx to fix Sparkle update issue in #74.

* script/ghreleases2appcast.go: Use working blackfriday.v1 (see #77) (#78)

* script/ghreleases2appcast.go: Changes for upgrades.s.n deployment (#80)

Basically, don't alter the download URLs for now, indent the XML for
readability.

* Fixup project move leftovers and update some documentation (#81)

* Fixup project move leftovers and update some documentation and contributing
* Cleanup xcode project with useless xgsyncthing target
* README.md: Add note about homebrew cask (ref #23)

* readme: Update contribution guidelines link (fixes #83)

* Bump syncthing resource to 0.14.50

* Use latest syncthing v0.14.51 resource

* CocoaPods: Manual patch EXPANDED_CODE_SIGN_IDENTITY: unbound variable #7708 bug

* Use syncthing v0.14.52 resource
@syncthing syncthing locked and limited conversation to collaborators Jul 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants