Yet Another Cycling Forum
General Category => The Knowledge => Ctrl-Alt-Del => Topic started by: Feanor on 20 February, 2020, 07:23:12 pm
-
I'm seeing behaviour in my browser ( Chrome ) which I'm not sure about.
( And am too lazy to diagnose myself! )
If I go to the home page:
https://yacf.co.uk/forum/index.php
That's fine.
But when I spod around and I get to:
https://yacf.co.uk/forum/index.php?topic=114931.0
Chrome is not happy, and declares it Not Secure.
What's it complaining about?
Is it Ham's not-https website link to http://cyclesafeandhappy.blogspot.com/ ?
-
Chrome doesn’t like http content in a https page. You can see the details if you click on something or other. But as I almost exclusively use Firefox now I don’t have it in front of me.
-
Developer Tools shows it's the "mixed content" it's objecting to, so yes - the presence of http on the page is making it mardy.
Recommendation: Ham needs to make his website SSL-savvy
ETA: X-Post with Ham!
-
....and I'd forgotten I had even started that site. I've now added an "S", just because
-
Seems my avatar image isn't HTTPS. Not sure why, it is just one the built-in options on the forum? Perhaps needs some tweaks to the forum settings.
(and now I have posted in this thread, it will also be shown as not secure)
There's also a few people with HTTP images in their signatures.
Links to other pages shouldn't affect the security of that page.
-
That seems like it should fixed by the forum. You, fuaran, could probably workaround the problem by downloading and then re-uploading the avatar, but other profiles would still cause the problem.
Users can also trigger the problem by putting http: URLs directly into their signature, e.g. Pingu's profile: https://yacf.co.uk/forum/index.php?action=profile;u=27 (https://yacf.co.uk/forum/index.php?action=profile;u=27).
-
Seems my avatar image isn't HTTPS. Not sure why, it is just one the built-in options on the forum? Perhaps needs some tweaks to the forum settings.
Comparing it to Ham's (which is https) it looks like a problem with forum-supplied avatars[1], but not the ones that have been uploaded by the users.
Presumably this stuff dates from the good old days[2], when encryption was for keeping secrets, and uninteresting content was sent in the clear for efficiency and cacheability.
[1] I must confess that I wasn't aware we had such a thing.
[2] When CPUs were slow and we didn't think about hiding metadata from The Man.
-
Hmm, I've used Chrome for years with the forum, and never had a problem with security messages.
-
Hmm, I've used Chrome for years with the forum, and never had a problem with security messages.
They've been progressively turning up the scorn on HTTP content (and self-signed certificates) over the years.
-
Also Safari will no longer recognise certs that have a life of more than 13 months from September. So everyone will have to renew their certs once a year.
-
I've only just realised it's Avril Lavigne.
I have added an "s" to the avatar directory path. Any better? Firefox never noticed.
-
Also Safari will no longer recognise certs that have a life of more than 13 months from September. So everyone will have to renew their certs once a year.
Been using Letsencrypt for a while on my web and email servers. Auto renewing certs every 90 days.
-
Also Safari will no longer recognise certs that have a life of more than 13 months from September. So everyone will have to renew their certs once a year.
Been using Letsencrypt for a while on my web and email servers. Auto renewing certs every 90 days.
Indeed. Certbot is my new best friend I've already forgotten I have.
-
I've only just realised it's Avril Lavigne.
I have added an "s" to the avatar directory path. Any better? Firefox never noticed.
Chromium now giving me a padlock instead of a !
-
Is that good? :D
-
Also Safari will no longer recognise certs that have a life of more than 13 months from September. So everyone will have to renew their certs once a year.
Been using Letsencrypt for a while on my web and email servers. Auto renewing certs every 90 days.
Indeed. Certbot is my new best friend I've already forgotten I have.
Here too,
My roundcube webmail box was just plain old http till tonight.
It's a centos7 box.
I read a whole lot about it before running it, but I'm mightily impressed by the certbot.
It found the vhosts apache configs, configured them, and it all *just worked*
Given that the various distros scatter their apache configs all over the place, I was well impressed that it just worked.
Then I had to manually edit the conf files to disable old TLS versions 1.0 and 1.1 to make testing site give me an A rather than a B rating.
https://www.ssllabs.com/ssltest/analyze.html?d=webmail.lowe-family.me.uk
-
is this anything that requires Dez's attention? I will mention it to him in any case. He hardly looks at the forum. If it's working, he just lets it get on with it. Now it's on secure, fast, "virtual" servers (I think that's what he said) it Just Works.
Until, of course, it doesn't.
-
From Kim's post, I think I've fixed it. The default path to the avatar directory assumes the forum will be HTTP for ever. Dez changed it to HTTPS years ago.
Anyway, it reminded me to renew the domain name for another two years!
-
I've just had one of those 'little moments' where I've realised something I thought was true is not.
I thought that proxying HTTPS could not be done.
But it can, Under specific circumstances. Basically, If you choose to trust the proxy and allow it.
Our work does. I noticed this when testing my home HTTPS webmail from work.
Our work proxies everything through an cloud-based outfit called Zscaler.
Visiting my HTTPS site normally shows the expected cert chain of:
DST Root CA x3 -> Lets Encrypt Authority X3 -> My HTTPS server.
But visiting it from work, I see:
Zscaler Root CA -> Zscaler Intermediate CA -> My HTTPS server.
WTF?
That's a broken path! That can't work!
Then I realised that the 'My HTTPS server' cert I see here is *not* the one I serve up.
It's spoofed.
Zscaler run their own self-signed CA, and issue spoofed certs for the target website.
Normally, no CA would issue certs to people who did not control the domains, so this would not work because no-one would trust a CA that issues spoofed certs willy-nilly.
To make this work, corporate IT have inserted the Zscaler root CA cert as a Trusted Root Cert on all corporate PCs via Domain Policy, so the spoofed certs are accepted!
So the connection is encrypted from my PC to Zscaler using their spoofed cert, passes through them in plaintext, and is then forwarded on a second encrypted hop to my server using my genuine cert.
So yes, a man-in-the-middle, by design agreement.
-
Yes, it's a fundamental flaw in SSL/TLS.
(There are plenty of other fundamental flaws.)
-
Then I realised that the 'My HTTPS server' cert I see here is *not* the one I serve up.
It's spoofed.
It's not spoofed as such.
client <--> proxy <--> https website
The proxy in the middle is decrypting the https traffic and then re-encrypting it with it's own private key. Which your corporate computer trusts because it has the proxy's CA.
This is probably what you meant, the explanation if for anyone else reading it.
Proxies that do this are evil.
-
Then I realised that the 'My HTTPS server' cert I see here is *not* the one I serve up.
It's spoofed.
The proxy in the middle is decrypting the https traffic and then re-encrypting it with it's own private key. Which your corporate computer trusts because it has the proxy's CA.
I thought that's exactly what I said regarding how it works, when I said:
To make this work, corporate IT have inserted the Zscaler root CA cert as a Trusted Root Cert on all corporate PCs via Domain Policy, so the spoofed certs are accepted!
So the connection is encrypted from my PC to Zscaler using their spoofed cert, passes through them in plaintext, and is then forwarded on a second encrypted hop to my server using my genuine cert.
So yes, I agree with that.
But I'd take issue with the bit that says:
It's not spoofed as such.
client <--> proxy <--> https website
The cert proffered to the client is *not* the one issued by the target https website.
It's been issued by the man-in-the-middle.
A cert claiming to be from a site which it is not is *by definition* spoofed.
What other definition of spoofed is there?
-
Also Safari will no longer recognise certs that have a life of more than 13 months from September. So everyone will have to renew their certs once a year.
Been using Letsencrypt for a while on my web and email servers. Auto renewing certs every 90 days.
Indeed. Certbot is my new best friend I've already forgotten I have.
Here too,
My roundcube webmail box was just plain old http till tonight.
It's a centos7 box.
I read a whole lot about it before running it, but I'm mightily impressed by the certbot.
It found the vhosts apache configs, configured them, and it all *just worked*
Given that the various distros scatter their apache configs all over the place, I was well impressed that it just worked.
Then I had to manually edit the conf files to disable old TLS versions 1.0 and 1.1 to make testing site give me an A rather than a B rating.
https://www.ssllabs.com/ssltest/analyze.html?d=webmail.lowe-family.me.uk
My Webmail server cert just did it's first auto-renewal yesterday.
I've just looked through the letsencrypt log for yesterday, and bloody hell, there's a *lot* going on.
But it *just worked*