In General, it’s easy to blame others for hacking (e.g. Russia, China, man in the moon)… I prefer to keep track on industry standards and reduce vulnerability as far as possible… of course there are some security measures colliding with usability, but then we are speaking about calculated risks & benefits. An F-grade website in our times is just an invitation for everybody to “fire in the hole”… and in the end it’s more realistic that the hacker is the script kiddie around the next block…
http://www.theregister.co.uk/2017/01/11/godaddy_pulls_unvalidated_digital_certs/
GoDaddy was obliged to revoke thousands of SSL certificates on Tuesday as the result of an unspecified software bug.
El Reg learnt of the cock-up from readers affected by the issue, who forwarded notification emails (extract below).
[quote]Due to a software bug, the recently issued certificate for your domain was issued without proper domain validation, and in accordance with industry standards as a Certificate Authority, we will need to revoke your certificate as a precautionary measure. The certificate will be revoked today (January 10) by 9pm Pacific Time. The software bug that created the issue has been remedied. We continue to closely monitor our system.
An affected website’s HTTPS encryption will still work even if its GoDaddy-issued certificate is revoked. However, visitors to your website may see error messages or warnings in their browser until a new certificate is installed. GoDaddy, which is issuing these replacement certificates free of charge, apologised to customers for the hassle caused by the slip-up in its notification email.[/quote]
In a blog post, GoDaddy said the bug was introduced six months ago on July 29 and impacted less than two per cent of the SSL certificates issued from July 29, 2016, to Jan. 10, 2017. Approximately 6,100 customers were affected, it said. That’s 8,850 certs, according to GoDaddy security veep Wayne Thayer.
GoDaddy inadvertently introduced the bug during a routine code change intended to improve our certificate issuance process. The bug caused the domain validation process to fail in certain circumstances, the CA explains.
In a typical process, when a certificate authority, like GoDaddy, validates a domain name for an SSL certificate, they provide a random code to the customer and ask them to place it in a specific location on their website, it said. When their system searches and finds the code, the validation is complete.
However, when the bug was introduced, certain web server configurations caused the system to provide a positive result to the search, even if the code was not found, it added. ®
Yay more reasons to hate GoDaddy!
I no longer work for Xojo, but here’s what I know of the issue.
I’m sorry to say, the payment section IS (or was, and as best as I can tell, still is) handled by the same web server with the F rated SSL. This is something I brought up with Geoff roughly a year ago (maybe more) when I first noticed it. The reason for the vulnerable SSL is the older IDEs. Many can only support SSLv2, so turning that off means the old IDEs cannot license.
They are between a rock and a hard place on the issue.
Well this is what I meant in saying security sometimes collides with usability. From my limited perspective from the outside I only see an unsecure main website. Wouldn’t it be great if these legecy heritage could be moved to another server or subdomain? Lead by example, eat your own food. This is what sells.
Well, I got my rating up to an A+ from an F (how embarrassing ;)) The changes were actually quite simple and if anyone wants a hand, I am willing to help out, but the following should get you started… These are changes I made to my MAMP server (which is just apache) and goes in to the VirtualHost directive section… I took the more strict approach to everything, so you may need to loosen it up a bit…
[quote]Header set Content-Security-Policy “default-src ‘none’; img-src ‘self’; script-src ‘self’; style-src ‘self’; frame-ancestors ‘none’”
Header set Strict-Transport-Security “max-age=31536000” env=HTTPS
Header set Referrer-Policy “no-referrer, same-origin”
Header set X-Content-Type-Options “nosniff”
Header set X-Frame-Options “DENY”
Header set X-XSS-Protection “1; mode=block”
Header set Public-Key-Pins “pin-sha256=“REPLACE_WITH_YOUR_HASH”; pin-sha256=“REPLACE_WITH_YOUR_CAs_HASH”; max-age=31536000”[/quote]
Apparently the Public-Key-Pins requires some kind of backup pin, but I am not 100% certain what it means and at this point am getting bored of reading… The last thing to work on is OCSP Stapling, so will post a follow-up once I get that done… (and maybe SPDY too)
I’ve turned off HPKP cause older browsers may throw out an error message. Same with CSP default-src for scripts and styles. These will disable all external linked ressources like Fontawesome etc. on the other side you can assign explicit Domains to them but as you said, this can be a boring job 
If it’s helpful here’s a good article (in german, use google translate) how to implement HPKP: https://www.techgrube.de/tutorials/http-public-key-pinning-hpkp-mit-apacheubuntu-webserver
Well, I did say I went strict There’s no content on my site, nor any external resources, so not a big deal for me, but I will need to get the settings right for the sites I host…
Subresource Integrity looks pretty easy, just time consuming to add to every link in the site that needs it…
https://wiki.mozilla.org/Security/Guidelines/Web_Security#Subresource_Integrity
Everybody’s content security policy will be different. It can be particularly complex to craft the right one for a site.
But be VERY careful with HKPK. The point about the backup keys is extremely important, and your ability to renew your SSL certificate could be in jeopardy.
With HKPK, you are telling the browser to ONLY accept one of the listed public keys for the specified amount of time. If you lose your private key and have no backups listed, your site will be inaccessible to users until that time has expired. And we’re not talking about minutes or hours, but MONTHS.
It means while renewing your SSL you must use the same CSR, or one generated from a previously approved key. For Let’s Encrypt, this is particularly an issue, as they always use a new CSR and key. They do support HKPK, but it is a big part of why I needed to write my own renewal manager.
HKPK is not to be trifled with. DO NOT turn it on unless you really understand what you’re doing with it, and have excellent backups of your keys.
So if I have the Private Key and CSR file nice and safe, it should be okay? But what is used for the Backup key? (seems like you have done this and it would save me some reading time to just ask, also, I’m lazy )
Just like any backup, it’s a “just in case” sort of thing. Maybe your server is broken into and your private key is stolen. Or your certificate gets revoked for some reason. In an ideal world, you’ll never need them.
lts face it: in an ideal world we wouln’t need website security at all. The web like 1995… we’ve made a long journey.
Why Website Security impacts Apps in App Stores:
https://arstechnica.com/security/2017/02/dozens-of-popular-ios-apps-vulnerable-to-intercept-of-tls-protected-data/