Hi Alvin, you're right. I've a fix "ready" for this issue (it took a bit more changes due some generated API responses...) but I'll commit it after my vacation when I have more time to review it and try it  (ETA end of October) because I'm not sure how one particular changed file will or will not be deployed in the Apache env and I would rather avoid breaking Synergy and (quite honestly) deal with it during my time off.

Thanks,
Lada

On 04/10/18 19:51, Alvin Thompson wrote:
Specifically, the assertion "Synergy should work just fine no matter which protocol is used, you can load the register page via Https just fine and I think all XHR requests are being made to relative urls so it should respect the protocol" isn't quite true because some assets are hard-wired as `http`.

On Oct 4, 2018, at 1:48 PM, Alvin Thompson <[email protected] <mailto:[email protected]>> wrote:

Unfortunately no. Can someone tweak the page source to load the page assets securely? It shouldn't be too involved at all.

On Oct 3, 2018, at 11:53 PM, Vladimir Riha <[email protected] <mailto:[email protected]>> wrote:

Hi, I'm on a vacation for the next month so it will have to wait I'm afraid. Synergy should work just fine no matter which protocol is used, you can load the register page via Https just fine and I think all XHR requests are being made to relative urls so it should respect the protocol. It is possible that some redirect causes change of https to http though. Is this the case?

Thanks,
Lada



4. října 2018 0:25:30 SELČ, "Jiří Kovalský" <[email protected] <mailto:[email protected]>> napsal:
Vladimír,

  do you think this would be an easy fix to keep the secure protocol
upon logging in securely? As Alvin pointed out Synergy redirects from
https to http for me.

Thanks for your answer!

-Jirka

Dne 3.10.2018 v 20:01 Alvin Thompson napsal(a):
Unfortunately it's not quite such an easy fix. The page itself relies
on assets which are also not secure (for example, jquery is loaded over
an insecure connection). The page source must be tweaked to load all
assets securely and the service it hits to submit the information must
be secured (if it isn't already). Then the page can be served over
HTTPS. Everything must be secure or nothing is.

On Oct 3, 2018, at 1:29 PM, Leo Donahue <[email protected] <mailto:[email protected]>> wrote:

Do you think whoever created the wiki page simply forgot to include
https in the url they posted here, on step #3.


https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NETBEANS_NetCAT-2B10.0-2BParticipants&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4&m=AOtFKoKXPMlll_r-jRLoGPxCEXD3yLe3upMrT0n4ipE&s=2C0Rknr0VdjT2muhBycBusrBosI8S2IbYeKRFk5YOFk&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NETBEANS_NetCAT-2B10.0-2BParticipants&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4&m=AOtFKoKXPMlll_r-jRLoGPxCEXD3yLe3upMrT0n4ipE&s=2C0Rknr0VdjT2muhBycBusrBosI8S2IbYeKRFk5YOFk&e=>

The cert for the domain is good for https

https://urldefense.proofpoint.com/v2/url?u=https-3A__netbeans-2Dvm.apache.org&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4&m=AOtFKoKXPMlll_r-jRLoGPxCEXD3yLe3upMrT0n4ipE&s=_x3q3qTK5RdcQVpzH-i4g8zxXDiMKqFypyA6elloINY&e=
<https://urldefense.proofpoint.com/v2/url?u=https-3A__netbeans-2Dvm.apache.org_&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4&m=AOtFKoKXPMlll_r-jRLoGPxCEXD3yLe3upMrT0n4ipE&s=GVMC0xnyxX2VmaOOy7u7WHcaSOgndYYwKNqr3mYYm9w&e=>

It seems like a very short time (3 months) to pay for...

On Wed, Oct 3, 2018, 11:14 Alvin Thompson <[email protected]
<mailto:[email protected]>> wrote:
That is not something the filler of the form could or should do; not
only does the web service that the form sends this information to need
to be secure, but the form itself must be secure.

It's possible that the javascript that the page uses to submit the
password (it's an angular.js app) submits to a service secured with
HTTPS already, but by that time it's too late. Since the javascript
itself was loaded over an insecure connection, it can be modified with
a "man in the middle" attack to submit the data somewhere
else--therefore it just can't be trusted.

On Wed, Oct 3, 2018 at 11:50 AM Leo Donahue <[email protected]
<mailto:[email protected]>> wrote:
Can you just change protocol of url to https?

On Wed, Oct 3, 2018, 09:25 Alvin Thompson <[email protected]
<mailto:[email protected]>> wrote:
Sorry to be a stickler for this, but the Synergy sign-up page (

https://urldefense.proofpoint.com/v2/url?u=http-3A__netbeans-2Dvm.apache.org_synergy_client_app_-23_register&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4&m=AOtFKoKXPMlll_r-jRLoGPxCEXD3yLe3upMrT0n4ipE&s=mWQUdJG3W154YmEs9jZHEDFyk-nrHEK50ztQAWmBFYA&e=
<https://urldefense.proofpoint.com/v2/url?u=http-3A__netbeans-2Dvm.apache.org_synergy_client_app_-23_register&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4&m=AOtFKoKXPMlll_r-jRLoGPxCEXD3yLe3upMrT0n4ipE&s=mWQUdJG3W154YmEs9jZHEDFyk-nrHEK50ztQAWmBFYA&e=>)
asks you to
submit a password over an insecure connection. Can this be moved to
HTTPS?



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Reply via email to