SSL Certificates

They tell you that the end-point of the encrypted transfer is controlled by the same computer or people that control the domain name. Assuming that neither your computer nor the server has been compromised in some other way, the data exchanged cannot be read, changed or replaced, and it is going to the right place. (That's a stronger than merely saying it can't be viewed.)

But of course it doesn't tell you that the address you think you are using is the correct one, or that the target server hasn't been taken over by hackers, or that there is no security bug in your browser, or that the certificate signing keys have not been stolen. As an internet user, you need to apply the level of paranoia you think appropriate.

I fully agree that search engines could be better in all sorts of ways. And I agree that it should be practical to do better in some ways at least, though I don't think there is any simple and general solution. And I don't agree that this has anything to do with SSL or certificates. (Topic drift is, as we know, the norm for this group. But you might want to separate it a little and give this a new subject line.)

Reply to
David Brown
Loading thread data ...

No. They verify that the computer contains the private key matching the certificate which was issued to the people who controlled that domain name *at the time of issuance*.

Read the Certification Practice Statement attached to any bank's certificate. You'll find that it requires the bank to vet IT staff and security constantly and carefully, and many other things - these documents are typically hundreds of pages of dense legalese.

The CA takes an active role in verifying that the bank complies with the requires of this extended verification, and that's why these certificates cost a lot more than a Letsencrypt certificate.

Also, if any one of the hundreds of trusted root CA certificates installed in your browser is controlled by a bad actor who can MITM your network (as happens in almost every enterprise, for example) then all bets are off. You make a request for

formatting link
and they instantly fabricate a certificate (or serve up one they made earlier) that looks entirely genuine (except for being signed by them, not whoever bigbank.com bought their real certificate from. Then they decrypt your data and forward the request to the original server, and you are none the wiser. As I said, this is commonplace in enterprise networks, because it's integral to their snooping and malware prevention strategies.

FWIW, the very first open source CA server was created and published by yours truly, as a set of CGI scripts. But I haven't worked in this space for many years now.

Clifford Heath.

Reply to
Clifford Heath

Here's the CPS from the CA who issued my bank's certificate. Just scan the table of contents to see what kinds of requirements it encompasses.

CH

Reply to
Clifford Heath

Fair enough - that emphasised disclaimer is important.

I don't believe /anyone/ - not even the lawyers that wrote it - actually read these hundreds of pages of legalese! But I don't need to read them to agree that they probably contain the requirements you mention.

Yes, exactly. (That is just expanding on what I have already mentioned.)

It all hinges on the secret keys being kept secret by trustworthy parties. But you already need to put a lot of trust in your bank!

Reply to
David Brown

You really only know that the other end has (access to) a private key for the public key that you are using to communicate with it.

Perhaps but I note for example that for example the domain

formatting link

Is still available. Typo lookalikes are dangerous although you might have to register it somewhere unfussy about what they will accept.

I had a friend who got quite badly stung by a typosquatting website on a well known commonly visited booking site once. The stupid little green padlock was there so he thought it was all OK.

--
Regards, 
Martin Brown
Reply to
Martin Brown

No, this part doesn't. An enterprise can control your DNS (so when you go to mybank.com you really don't) or they can MITM the connection on a gateway even if they serve the real IP addresses.

So you get a TCP connection to an enterprise gateway, and it sees that you want to talk SSL, so they fabricate (and sign) a certificate that says it is from mybank.com. It's signed by a CA you trust (the one they installed in your enterprise laptop or phone), and everything looks rosy. Then they forward the traffic to mybank.com through another SSL connection, and neither party is any the wiser. Meantime they can record all your traffic in plain text.

Once you trust any root certificate, the owners of the matching private key can prove *anything* to you... unless you happen to open the certificate and discover that it isn't signed by the CA they actually use, but by the bogus one.

Clifford Heath.

Reply to
Clifford Heath

A lot of schools also do this. Every computer which is used on the school network has a special certificate installed which allows their proxy server to intercept https connections and report on anything "inappropriate". I have often wondered where the liability would lie if a banking scam caused significant losses to a teacher using the school network for internet banking.

John

Reply to
John Walliker

I hope you managed to get the information you need to help your friend before the thread decayed in traditional s.e.d. style. The conclusion has to be that you use Let's Encrypt for a simple and entirely free system to get a valid signed SSL certificate - it's what just about everyone else does these days.

As for all the other weaknesses and attack vectors of the internet, neither you nor anyone else can fix them - you just have to live with them.

Reply to
David Brown

Yes and no. I had actually found the free (for 90 days) certificate providers before this thread or at least very early on in the thread. That part is fine. But the web site still needs to be modified to work in https mode it would seem.

--

Rick C. 

++ Get 1,000 miles of free Supercharging 
++ Tesla referral code - https://ts.la/richard11209
Reply to
Rick C

Let's Encrypt is free without time limit. (Of course each certificate has an expiry date, and needs regularly renewed - but that can be automated.)

That should be handled easily once you have a certificate in place. Simply avoid using "http://" in links, anchors, etc. As a general rule, you shouldn't use absolute addresses anyway unless you really need them

- relative addresses make it easier to move the pages around, such as between a test server and the real server.

There have been suggestions in this thread that http (port 80) should have pages set up to redirect to https (port 443). I wouldn't bother - simply drop the http port 80 altogether. (Leave it free for Let's Encrypt scripts.) For normal web usage, plain http is basically dead now, and many browsers won't use it without all sorts of complaints and "are you sure?" boxes.

Reply to
David Brown

I wouldn't either if it wasn't so trivially easy, at least on my setup.

If it has to be listening anyway then you can't drop it but it's your choice whether or not you want a redirect to https. With a redirect then someone trying to get to yoursite.com will automatically end up at

formatting link

I get no complaints from Firefox here:

formatting link

Reply to
Edward Rawde

It is indeed trivially easy to do. But that doesn't necessarily make it worth doing - especially as it makes one of the convenient ways of running Let's Encrypt a little less easy.

What is "it" that is listening? You need your webserver listening on port 443 to serve the site. For the simplest way of running the Let's Encrypt scripts, you have them running on port 80 briefly for renewals or when you want a new certificate (you can run them automatically once a week, for example). So if you have your webserver also listening on port 80 - despite it being useless - you then have to stop your webserver while renewing your certificates. That's not hard either, of course.

Unless you are expecting people to use seriously outdated browsers or some other unusual methods for accessing the website, http is no longer useful. And you don't even need a redirect - if someone puts http into the address line, and the browser fails to make contact, it should try https anyway.

It seems I was wrong about that. I have certainly had complaints in some cases. In fact, I have found it so inconvenient in Firefox for some cases where I need to use http, such as for accessing web interfaces to some firewalls, routers, switches, etc., that I generally use Chromium for that kind of thing. Perhaps there is something else going wrong in those cases. So thanks for the correction.

Reply to
David Brown

Nginx in my case. On 80, 443 and at least two others. Yes there's a restart when the certificate renews but I never notice. If the server is listening on 443 then in my view it may as well be listening on 80. After all it's the same server (in my case). But I don't see any point arguing over this because I rarely see two Internet connected systems set up the same. Much of it depends on personal preference.

Reply to
Edward Rawde

OH, of COURSE! Most web browsers now REQUIRE an https connection, and will either just go blank, or give a scary-sounding warning if it doesn't connect via https.

Jon

Reply to
Jon Elson

The certificate is fine and expires in march. going to the plain http:// site doesn't redirect you to the SSL version, so you get security warnings from the browser about the site not being secure. Setup a redirect from http:// requests to https://site.whatever and you'll be OK. cpanel should have a way to enforce https over http, where possible. MAybe search for

301 redirect http to https
Reply to
Cydrome Leader

friend who had a web site for his non-profit and I don't quite understand the details. The web hosting provides a certificate which I copied to Cpane l and it says it is installed, but opening the web page still reports a pro blem with security.

icate is not issued by an authority, but rather self signed. I found a site that gives out 90 day free certificates and installed one. Just typing the web site URL doesn't show a safe site, but typing https: manually does, ho wever the web site doesn't work correctly. The initial page has some sort o f fancy dancy animated text that doesn't work and you can't get past that.

t there who can offer some advice?

s

That is understood. But the site itself contains references to other pages on the site that are also directly coded to http rather than https. I hav en't found a way in cpanel to do this as a blanket redirect.

--

Rick C. 

--- Get 1,000 miles of free Supercharging 
--- Tesla referral code - https://ts.la/richard11209
Reply to
Rick C

I used .htaccess to fix this sort of thing.

formatting link

.htaccess is good web site magic, and well worth learning! Where you put the .htaccess it covers that directory and all sub-directories the same.

You can password protect directories, protect certain file suffixes, and have a great time blocking bots (robots.txt - something else to read up on).

You might want to also read up on directory permissions - Write, Read, Execute permissions can also be handy.

Your temp/tmp directory needs to be placed correctly - something else to learn...

Logs are your friends!

Hope that helps!

John :-#)#

Reply to
John Robertson

e:

a friend who had a web site for his non-profit and I don't quite understan d the details. The web hosting provides a certificate which I copied to Cpa nel and it says it is installed, but opening the web page still reports a p roblem with security.

ificate is not issued by an authority, but rather self signed. I found a si te that gives out 90 day free certificates and installed one. Just typing t he web site URL doesn't show a safe site, but typing https: manually does, however the web site doesn't work correctly. The initial page has some sort of fancy dancy animated text that doesn't work and you can't get past that .

out there who can offer some advice?

//

ings

m

uld

r

ges on the site that are also directly coded to http rather than https. I h aven't found a way in cpanel to do this as a blanket redirect.

n).

Thanks for the post, but neither my friend nor I know enough to make use of the article you linked.

--

Rick C. 

--+ Get 1,000 miles of free Supercharging 
--+ Tesla referral code - https://ts.la/richard11209
Reply to
Rick C

I felt the same way about .htaccess when I first started using it. It isn't that hard to learn if you simply take small bites at it.

You may already have a basic .htaccess file in your root directory - set up by the technician(s) who maintain the host servers for your site.

You can edit the .htaccess file with a simple text editor (not a fancy Word of other advanced editor that interjects invisible crap) - I like BBEdit on my mac for basic editing, your operating system should have something that works fine. I am not familiar with Windows after fifteen or so years in osX land so can't advise you on an editor for that, but I am sure there are suitable ones there too.

I suggest tring adding one small change such as:

-----------------(.htaccess text)--------------

# Canonical HTTPS/non-WWW RewriteCond %{HTTPS} off [OR] RewriteCond %{HTTP_HOST} ^www\.coldwatersafety\.org [NC] RewriteRule (.*)

formatting link
$1 [L,R=301]

-----------------(end)----------------

and then clear your browser cache and test your web site. Best to check with at least two different browsers, and perhaps try using a phone browser to see if you now are forced to ssl only.

If not, then delete the lines, restoring .htaccess to its original state and then double check the site works as before...

I can't think of any Cpanel setting that will accomplish this, however why not ask the host tech support folks for advice? Perhaps they have a default .htaccess that can drop in your root directory? You should have access to Support in Cpanel...

John :-#)#

Reply to
John Robertson

Maybe it's time to change the code? They browser is doing what you are telling it to do, and your instructions are bad/obsolete.

Reply to
Cydrome Leader

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.