I decided to upgrade my site to the new version of Ubuntu as I haven’t done that for a couple of years. It is always a nice thing to work on when I am on vacation as it is the sort of thing that I don’t really get around to normally when I am busy. What a pain that ended up being.

The Upgrade for the OS itself went very smoothly as it seems to normally do so for Ubuntu. But the upgrade to the newer version of PHP broke everything with my site. As I think back actually I think this happened last time when I went from Ubuntu 14.04 to 16.04 as well and it jumped from php5 to php7. I ended up with about a 3 hour outage trying to sort everything out.

Recently Let’s Encrypt announced that they would be supporting wildcard certs. I was pretty excited to hear about this as many times I would like to get certs for machines that might not be accessible on the internet. Currently I didn’t see an easy way to do this. With the new certs you could get a cert on your web server for your domain and use that cert on all the other machines in your domain that need TLS as well.

Recently I ported my domain hosting from Godaddy to Google Domains. My main reason for doing so was to save money. Domain names on Godaddy cost $3 more per year, plus they charge you for privacy on whois searches whereas Google includes that for free. It was a fairly easy process to transfer my domain names in, but configuring the DNS was a little bit weird as their zone file editing interface was different that godaddy’s. However I thought I had it all good and working so I was happy with my setup.

Recently one of my friends was working on a Spring Boot project and he was having trouble finding an example of how to configure user login for his site with Spring Boot using JPA. I had mentioned that there is some mention of configuring security in Greg Turnquist’s book Learning Spring Boot. He had just purchased Spring Boot in Action and I don’t think he was rushing to grab another book, but he hadn’t been able to find a good online tutorial.

I received an email a week or 2 ago that I was accepted into the EFF’s Let’s Encrypt Beta program to try out their new SSL certificate generation service. It uses the Automated Certificate Management Environment (ACME) protocol. I have been really interested in this program since it was announced as in the past when I have used Start SSL’s certificate system I found their whole validation system to be a little clunky. The idea of a nice automated program that does all the work for me sounded very appealing.

I saw a post on twitter about Security Headers. Basically Security Headers will scan your website and check for some common HTTP Headers that you should be including to make your site more secure. They also include helpful links as to how to fix the issues it finds. On my first scanned it warned me of the following: MISSING Content-Security-Policy, MISSING X-Frame-Options, MISSING X-Xss-Protection, MISSING X-Content-Type-Options, MISSING Public-Key-Pins, and X-Powered-By. After going through their documentation I added all of those headers except for Public Key Pins. I am not 100% on that, my concern is when your certificate expires and you replace it (which on a free certificate happens every year) do you end up with people getting an error on your website for the next week cause they have an old key pinned? Not sure enough about that to actually enable it, which is why I hadn’t previously enabled it. The other headers though I didn’t realize could be an issue so I promptly corrected them. The one thing I couldn’t easily fix was the Server header as apparently that is compiled into NGINX and I wasn’t feeling like compiling my own from source. I was able to remove the version string though. All in all they give some very easy configuration changes you can make to help prevent attacks against your website and I strongly recommend giving their tool a look.

So a little while back when I had been playing with Pagespeed I somehow managed to break certificate stapling on my server. So when I ran the Qualys SSL Server Test my score had fallen to a B! I messed around and tried a few things and I had no luck getting it to work. One of my friends said the site started to give weird errors under Chrome on Android. Then I was reading this CertSimple Blog entry yesterday and they mentioned the Mozilla Server Side TLS Project, which I don’t think I had heard of. Basically what it does is you enter your server version and your OpenSSL version and how aggressive you want your security settings and it will generate a sample config for you. It will tell you based on how aggressive your settings are what the minimum browser versions are. For example of of the differences between Intermediate and Modern is that they drop support for TLSv1 in Modern and only support TLSv1.1 and TLSv1.2. For most browsers this doesn’t seem to be an issue but if you are running IE that means the minimum browser version is IE 11. I debated whether I should drop TLSv1 support or not, but I figure if I keep it I can support IE back to 7, though I can’t imagine any software engineers that might check out this blog using IE anyway. For now I have kept it but one of these days I will drop it because given the rate of SSL issues with Freak and Logjam lately, it is only a matter of time before someone finds a hole in TLSv1.

The Electronic Freedom Foundation has released a nice post on how one should configure their server to pass the Qualsys SSL Labs test with an A+. Given that when I initially setup my site it took me like 3 hours of messing around to get my site to pass with an A+ I figured I should share this post with everyone as it is so useful. Check it out here!

I was checking the Spring Blog today to see what was new after taking much of the week off. I came upon the following entry. Of course I was very interested as Spring Security 4.0 has been hyped for a few months now so I figured I would check out the migration guide from 3.2 to see what will be involved for us to upgrade. I found this is the new feature section. They have added a feature which will now automatically prepend ROLE_ to any roles you use in Spring security if your role doesn’t start with that. So if you have a role called ROLE_USER for a standard user you can now just say @PreAuthorize(“hasRole(‘USER’)”).

I just wanted to mention signal has been released so for all the iPhone users out there it is definitely worth installing. Signal is an implementation of Text Secure on IOS. Given the insecurity of text messages and how many other messengers have varying degrees of security Open WhisperSystems has released Signal. Some popular chat programs like WhatsApp are starting to encrypt but they aren’t always encrypted. One of the biggest benefits of Signal is they released the source code so that anyone can audit the code. Granted if you are installing it from the iTunes store there is still the risk of a back door being in there, but one inclined and with a developers license could build their own and install it on their phone. Of course that also assumes that your copy of XCode hasn’t been tampered with. At the end of the day if you are a target they are probably going to get your stuff, but the benefits of widespread use of secure products would be to disallow wholesale metadata and data collection that has been alleged to have been happening so that innocent people are left alone. The EFF has a nice scorecard that ranks the security aspects of different messenger apps. Here is another story suggesting the use of this app. If you are on Android Signal is an implementation of TextSecure.

I came across this blog post on Hacker News this morning. I thought it was a great blog post so I figured I would share it. Here there is a group of people that were trying to weaken the HTTP2 standard by not requiring TLS encryption in the standard as originally proposed and Google and Mozilla are working around that by requiring it for HTTP2 standard in their browsers. I think they are taking the right stand here as there is no excuse to not be encrypting anymore, and by them taking this stand it will encourage more people to get on board with TLS while at the same time getting the performance benefits of the new protocol.

Good news this week. Our purchase of Clover was approved and we will have our license keys in a matter of days. As of tomorrow it is going into our build and Cobertura is getting ripped out. You may recall I previously wrote about my issues with Cobertura. One problem was the latest version at the time 2.0.3 didn’t work with Powermock, even though 1.9.4.1 did. And the second issue I was having with it was the lack of Java 8 support since we are close to upgrading on our project at work. Well oddly enough early in this week I saw Cobertura had a new maven plug and a new release 2.1.1. I immediately updated to the 2.7 plugin to give it a go and it promptly failed on Powermock like 2.0.3. So I didn’t feel bad at all when 2 days later I found out our Clover purchase request had been approved.

I am currently reading Iron-Clad Java: Building Secure Web Applications by Jim Manico and August Detlefsen. This book basically takes you from zero to doing a decent job of locking down your webapp. It starts with security basics and then covers authentication and session management, and then access control, followed by Cross-Site Scripting Defense, then Cross-Site Request Forgery Defense, and much more. I am only a couple of chapters into the book so far. What I like about it is that they include security anti-patterns as well. These are things that you commonly see people doing in the name of security, but really aren’t the way you want to go about locking down your app. Having been through a professional security audit on a project I worked on and having fixed many of these potential attacks in my career it is nice to see this all laid out in one place for newer developers. At the same time the detail is so good that even experienced web devs should probably read this book and keep it as a reference. If you have gone through the OWASP stuff there won’t be a lot of new stuff here from what I have seen, but I feel like they have made the material very accessible. Anyway long story short I recommend this book and after reading it, one really appreciates all the stuff Spring Security does for you out of the box.

Today I came across the following news. The Chrome security team is considering marking all non-HTTPS sites as insecure (since they are.) Check out the story here. What this means is that if you don’t setup SSL on your site you are likely to lose users who are going to fear if your site is safe to use. Google has already announced that they are going to score pages higher in their search index if they use encryption and this is just more incentive for people to take the time to secure their sites. In 2014 it no longer makes sense to run a non-encrypted website. Techdirt also covered the story here.

When I was working on this site on of the first things I did after setting up SSL was to run the Qualys SSL Labs Test on my site. This tool will analyze your site security and point out any weaknesses and assign a grade to your site. I initially scored a C and used the test results to get this site up to an A. When I got to an A I thought I was doing well as I had robust forward secrecy and my scores 100, 95, 80, 90. Then I saw this blog post over here and noticed his site while also had an A score he had a key exchange score of 100. This sent me down the rabbit hole of tweaking SSL configs to figure out how to really get a high score on this test.