SoylentNews is people
SoylentNews
Back in March I asked you guys if I should put SSL on my mcgrewbooks.com site, since it appeared that it would raise my hosting cost by $25 a year, and there was no technical reason to have it; there is no personal information collected whatever.
I gave a lot of thought to the comments for months, and yesterday decided to go ahead and spend the money; I just put three grand on my mortgage principal. So I went to R4L’s web site to find where I could add SSL. I couldn’t find it.
However, their help is actually a Canadian who helps through text chat, who informed me that paid hosting came with SSL, I simply had to turn it on.
Well, it wasn’t that simple, as they’re upgrading their tools and I ran across a couple of 404s. But I finally found the correct widget to click, so the unnecessary lock is no longer broken.
My other site still has a broken lock, but it’s a “free” site. Registration there is $15, but you get ten megabytes of hosting. Those are the kind of site that an extra $25 buys SSL, and you might as well pay for hosting. It isn’t much more, and it isn’t hard to fill ten megs. Almost all of the images at mcgrew.info are either on Wikipedia (which reminds me, I should donate again) or mcgrewbooks.
I wish I would have known that five years ago! But I’m still more than happy with R4L.
Since R4L is Canadian, whose internet laws apply? America’s? Canada’s? Both? Neither?
(Score: 0) by Anonymous Coward on Wednesday October 13 2021, @09:11PM (2 children)
Using HTTPS boosts your site's PageRank.
(Score: 1, Touché) by Anonymous Coward on Wednesday October 13 2021, @11:36PM (1 child)
You still use Google? Why?
Next you'll be saying you use Android.
But seriously, for a personal site, why give a flying f$ck about search rank? Maybe keep the riffraff and bandwidth wasters away.
(Score: 0) by Anonymous Coward on Thursday October 14 2021, @03:58AM
You don't have to use Google yourself to benefit from an increased rank. In fact, the benefit comes from other people using it.
(Score: 0) by Anonymous Coward on Wednesday October 13 2021, @10:43PM
It is based in Texas, no less.
(Score: 2) by DannyB on Thursday October 14 2021, @02:48PM (14 children)
A decade ago, I had to learn to set up Apache Tomcat with SSL/TLS. (Yes, my mind is addled by Java) First I had to get the certificate, which was easy because corporate IT takes care of that. Then I had to study the documentation, set it up internally and test it. Then diddle and fiddle with it to get the best configuration of available ciphers and other properties. Testing it with SSLLabs.com [ssllabs.com] sure helps to get everything right.
Once I had that down pat, I now run everything, including all internal servers using SSL/TLS. Just to maintain proficiency. All machines, even inside the private network have individual names like: G28Q5J0Z.xyzcorporation.com. Since the certificate is a wildcard cert (*.xyzcorporation.com), I can use it not only for production but for internal servers as well. IT helpfully got me a second wildcard certificate so that the one used on production (on the public internet) is a different actual certificate (different signature) than the one used on all internal servers. Even though it is the same domain wildcard cert. (This was their idea even!)
Once over the initial hump of learning, I keep up with routine changes in the SSLLabs report. Sometimes having to add new ciphers and remove old ones no longer considered secure. Or other minor changes.
The biggest thing this does is to maintain proficiency. All of the servers I run inside the network for testing and other purposes use SSL/TLS. It is just part of how I set up Apache Tomcat. From a "template" of sorts.
Performance is excellent, so there is no reason to use plain ol' HTTP for anything, even internally.
That's my experience. It may differ from others.
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 2) by RS3 on Thursday October 14 2021, @05:32PM (11 children)
I'm a part-time admin for some servers. It's not even part-time- they just run. I'm a little embarrassed to admit I can't get https working. But again, it's not even part-time- I may spend an hour a week doing it, but many hours doing all the examples and documentation for https on Apache. Apache runs, but trying to see the https site gets nothing, and no useful error messages. Any thoughts on where I can find a useful quickstart tutorial?
(Score: 3, Informative) by DannyB on Thursday October 14 2021, @06:13PM (7 children)
Unfortunately, I don't use "Apache", but I use "Apache Tomcat", which is a Java "application server" (more than a "web server"). Tomcat is from the overall Apache project and of course Apache 2 license.
Another thing I had going for me. I was able to devote my full time and attention to this matter while getting paid to do so. That helps a lot right there.
Just googling, there seems to be no shortage of articles on setting up Apache with SSL/TLS.
You will need to have a certificate for your domain. From a Certificate Authority (CA) that is recognized by all popular browsers. (There is a whole process in getting that certificate.)
The following is a lazy and loose summary.
The certificate comes in a container. There are various types of containers. A common one is PKCS12. There is a password you need to "open" or "peek inside" the container. (Sort of like a zip file.)
The container will have two basic elements. (1) a private key, and (2) a certificate for your domain.
The private key is the secret you want to protect. Since the container file requires a password, you really want to protect the password to your certificate container. The valuable secret key is too long to memorize or write down. Without going into detail, the secret key along with presentation of the certificate enables a web browser to verify that your web site really and truly is in possession of the certificate. Also your content is encrypted in both directions. It is also in principle possible for the browser to use a certificate to prove who you are to the server. The common case is to prove who the server is -- to know that you aren't giving your credit card info to someone pretending to be Amazon.
You can relax and be sure that you are safely giving every last private detail of your life to Google, and not someone claiming to be Google.
I don't know that I can give you much help, except for Tomcat, which I know pretty well. I know some neat tricks with Tomcat, like setting multiple server instances on different ports on a single OS. Each instance can be quickly pointed to a different Tomcat software version, different web content, and different Java version. So I could make some changes in a script, and make "server 11" point to a different Java runtime, different Tomcat version, and different content, with just a few seconds downtime. Multiple instances can share a common Tomcat software, and common Java software to avoid redundancy. It is also easy to download a newer Java and test it out on one of the servers to make sure everything works -- or to quickly switch it back.
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 2) by RS3 on Saturday October 16 2021, @06:52PM (6 children)
Thank you so much DannyB. Some years ago I inherited a Tomcat server, but those websites were being shut down, so I did very little with it. I know much of what you wrote, and thank you so much for the confirmation.
Re. cert: for testing I generated a self-signed one. It's easy. I won't use it (them?) in production because they cause a browser to prompt the user to accept the cert, and that's not a good thing. When I get the mechanism working we'll buy a cert, or get a free one if it's available for this situation.
Yes, I've run through the many tutorials, each of which has some differing approaches. Apache has some "interesting" ways of setting up .conf files and their directory tree, including .htaccess files and their parameters, and I'm just never sure it sees everything. 'apachectl configtest' just gives an okay or not okay, AFAIK.
As I mentioned below, it's mostly that I need a block of time to focus on it and I'll get it. And as AC below said, getting better mod_ssl logging will help. But I don't think mod_ssl is even getting called...
(Score: 1, Informative) by Anonymous Coward on Sunday October 17 2021, @02:33AM (3 children)
Unless you absolutely have to have it, you should disable per-directory configuration overrides. They are an accident waiting to happen and can hurt performance.
The way that makes sense to me is to put all global options in the global configuration files, all module configuration in the module configuration files, and the site configuration into the sites configuration files. If you keep the scopes distinct, it makes sense. Something like logging or default permissions should be set globally. Most TLS options should be set at the module level. Then you should have at least two site configuration files, one for HTTP and one for HTTPS, that set the options specific to them like DocumentRoot or RedirectMatch.
A final note is that following different tutorials with different approaches is usually a bad idea since your changes get spread around many different files. What I would do is try to get your configuration as close to stock as it is possible to do safely first. Then I would enable mod_ssl and mod_alias with the appropriate symlinks. Make sure they get loaded at startup. Then I would add a site config file to your available directory and do the basics of having all URLs aimed at that virtual host redirect to the HTTP version. That will teach you how to get TLS going and how to write the appropriate RedirectMatch setting. Once you get your TLS setting hardened enough in the module config and the site working, you copy the DocumentRoot or however that is set up to the HTTPS site config. Once that works, you add the redirect to the HTTP site config and get rid of the DocumentRoot. The benefit of doing it this way is that you can get each part of the set up step by step without endangering the rest of your website and on your own time. I probably made that sound too easy and glossed over steps, but you can always ask.
(Score: 2) by RS3 on Sunday October 17 2021, @05:20AM (2 children)
Wow, thank you for all of that. Yes, I'm pretty careful and consistent with config files and most of what you describe. But when I get some time to try it again, I'll use everything you've so kindly written, and thank you again.
It seems different Linux distros set up Apache different ways, so that makes following tutorials / how-tos a bit complex, but I got it together and Apache would run, just no response to the https request. I've been doing systems admin and software development for a long time (hw too!) so I can handle it. It's just a bit annoying to try to correlate a tutorial aimed at Debian and derivatives, when I'm running CentOS. But I'm probably about to switch to Devuan, so, well, that first.
I like the idea of separate config file for http and https.
It is a live server with many virtual hosts.
I'm very good at copying httpd.conf to httpd.conf_10-14-21 or some such, and make backup copies.
It might be weeks before I get enough time to focus on this thing. Main job and other critical responsibilities are taking up all of my time these days...
(Score: 1, Informative) by Anonymous Coward on Sunday October 17 2021, @07:30AM (1 child)
I mentioned this to a person I know, she said CentOS doesn't use the standard directory setup of most distros. However, we've (well, she) changed it so it is closer to the standard setup on our machines but that isn't the default. Regardless, setting this up should be easier with Devuan, which does a bit clearer (IMHO) separation of global/module/site configuration by default. And when you do come to that phase, you don't have to do all the TLS stuff at once. Each of those steps is doable on their own without breaking anything that works and can have plenty of time between them.
She also said that if you have a standard CentOS setup, certbot from the EFF can do the TLS configuration changes for you automatically, including the module installation and RedirectMatch. That might be worth a try if you want a safe and usable setup with minimum effort and don't really care to learn step by step.
(Score: 2) by RS3 on Sunday October 17 2021, @05:45PM
Thank you so much! I had not tried certbot and probably wouldn't at the time. I generally don't like, well, haven't had good results from software that tries to write / edit configuration files. That said, I've used many and learned from the outputs, but kept copies of default / previous iterations. A great example is "samba swat". It showed me some things I didn't know about, but it made a mess (which I cleaned up). But I'll try certbot with the new system, whenever I get around to it.
I'm a Slackware guy firstly, but I haven't deployed it live. As much as I like it and am totally familiar with it, I'd hate for someone else to have to deal with it, for whatever reason, and curse me for installing Slackware.
I did not like Red Hat when it came out, and it took a while for me to warm up to it. Acquired taste and all I guess.
Tried and like many others. I prefer to stay away from systemd. Someone here (you?) gave me some great info on systemd, but I just don't like the idea of it, and I don't see how it's necessary or a benefit. I'm good with admin, and I need stability and predictability.
I really like Alpine but like too many it doesn't have good package management (IMHO). So it's on to Devuan, and I think I'll like it.
Thanks!
(Score: 3, Informative) by DannyB on Monday October 18 2021, @04:04PM (1 child)
Here is a tip. Don't just generate a self signed cert.
1. Generate a self signed cert that is used to sign other certificates. In other words, your own private certificate authority.
2. Now using that private CA cert, generate and sign a new cert for your domain.
3. Take the self signed cert (without the private key), and install it in to one or more web browsers within your organization so that those browsers now trust that "CA". If you have a large fleet of Windows boxes joined to a corporate domain, this is easily done to install an internal private corporate certificate into ten thousand PCs.
Now your internal machines will honor your domain certificate and allow real testing before buying a certificate.
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 0) by Anonymous Coward on Tuesday October 19 2021, @02:44AM
The best practices now is to use a 3 level CA system. Generate the self-signed cert and add the public part to the trust store. Use its private key to sign the intermediate certificate, split the root key into secret shares and then destroy it. Then use the intermediate certificate to do all the heavy lifting. That way you leave yourself with various outs when compromise occurs, among other benefits.
(Score: 1, Informative) by Anonymous Coward on Friday October 15 2021, @01:46AM (2 children)
Try cranking your mod_ssl LogLevel . Also check that it isn't something else like your firewall or a reverse proxy dropping requests.
(Score: 2) by RS3 on Saturday October 16 2021, @06:32PM (1 child)
Thank you for the tips, I'll try those things. Main problem is it's not a full-time job, and I get very little bits of time here and there and can't focus on the problem.
I doubt it's firewall, as I have the ports open (80, 443, and probably 8080 and another one just for good measure) and can ping it, etc., and 80 works.
I'll definitely look into ssl logs and loglevel- just haven't had time to devote to it.
Not really sure what a reverse proxy is, but I don't think there is one. I built the server from scratch (CentOS) and I'm particularly careful about what gets installed.
There's simply a "gateway" (advanced one) that does static NAT for me, so I know what ports and IP addresses go where.
Thanks again.
(Score: 0) by Anonymous Coward on Saturday October 16 2021, @11:07PM
If you had a reverse proxy, you'd probably know it. But it doesn't hurt to double check your services and listening ports. Also check the firewall anyway, because I've skipped checklists or fat-fingered (4433, 800, 70, etc.) it so they aren't in the table.
(Score: 2) by mcgrew on Thursday October 14 2021, @06:03PM (1 child)
Things obviously got a lot easier in the last decade.
Carbon, The only element in the known universe to ever gain sentience
(Score: 2) by DannyB on Thursday October 14 2021, @06:15PM
There were changes in the last decade. And things did get easier.
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 2) by RS3 on Thursday October 14 2021, @05:37PM (5 children)
Frankly I think https is way overblown (like so many things these days). The problem is: more and more browsers are refusing to render an http page without popping up a warning about how insecure the site is. That interstitial warning is causing many people to steer clear of a perfectly okay website. But the browser has no way of knowing it's just a site to be read from, not one where you send information to (web forms, etc.). So that's driving the necessity for https.
(Score: 2) by mcgrew on Thursday October 14 2021, @06:05PM
It shouldn't be necessary at all for something like a magazine or newspaper, except subscriptions.
Carbon, The only element in the known universe to ever gain sentience
(Score: 3, Interesting) by DannyB on Thursday October 14 2021, @06:20PM (3 children)
I don't disagree with your argument.
However I find that view interesting when about fifteen to twenty years ago everything was in clear text on the internet and everyone was clamoring for everything to be encrypted. The rush for encryption everywhere increased in 2013 with the Snowden revelations.
I kind of like the fact that encryption is universal. An attacker, even a sophisticated one, must jump through some hoops in order to snoop.
With TLS able to "wrap" ordinary TCP connections, many protocols are now encrypted. We need an encrypted version of the "finger" protocol.
Why does the government need to know what news articles I read, what magazines I read, etc.
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 3, Interesting) by RS3 on Thursday October 14 2021, @10:44PM (1 child)
Yes, completely agree on all points. What I don't like, and I don't have a simple solution, is apps- foreground or background- communicating with someone somewhere and it's all encrypted. Smsniff, etc., can't reveal what's going on.
Cynical me thinks the govt. has all of us under surveillance all the time anyway. But that said, they had to pay the Israelis to crack that iPhone. Or was that a smokescreen...
(Score: 1, Informative) by Anonymous Coward on Friday October 15 2021, @10:06PM
Maybe you'd like something like squid. You can control what gets checked and what doesn't that way.
(Score: 0) by Anonymous Coward on Saturday October 16 2021, @04:34PM
Obviously, they need to be sure you're not a domestic terrorist plotting to overthrow our Democratically Elected™ government. Why do you hate our freedom DannyB?! What are you hiding?!