I saw this weird warning in Chrome’s DevTools while looking at a site:
OTS parsing error: invalid version tag
Uh-huh. That’s a bit strange. Unable to download fonts? What caused that?
Well, I tried going to the font’s URL – and got the ‘Page Not Found’ page! Well, that’s annoying – but a 404 page is clearly not a font.
However, this site’s error pages return HTTP 200 – so Chrome expects a font…
Make sure your error pages return a correct HTTP status code. If you don’t, it can cause problems. Normally, I find that it’s false positives on automated penetration tests, but this is a new and exciting variation.
Scott Helme has posted a number of interesting blog posts recently:
I mean, he’s a bit of a LetsEncrypt fan, but equally, their certificates are as good as others, and EV Certs and SSL Warranties do seem to be sources of revenue generation, rather than offering something useful.
What I’d really like is an easy way to use LetsEncrypt with IIS; for a long time it has seemed like a second-class citizen. Or maybe scripting is just more awkward in Windows. Either way, it’d be great to have simple tooling to support automatically renewing IIS site certs.
Then we could reduced certificate lifetimes and overcome the problems of the broken revocation process in certificates.
This is a bit of an aide-memoire, based on https://blogs.msdn.microsoft.com/benjaminperkins/2017/11/15/how-to-create-a-self-signed-san-certificate-wildcard-certificate-vs-san/
The short form is, you can do this in PowerShell:
- Open Powershell, running as administrator.
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "example.local" -FriendlyName "example.local" -NotAfter $([datetime]::now.AddYears(5))
- Go to “Manager Computer Certificate” or run CERTMGR. You should see your certificate
Next, we want to trust this certificate. We’ll need to export it.
- To export the certificate file you just created as a .PFX file, right click on the certificate, All Tasks -> Export…
- When the Export menu item is selected, an export wizard is run. On the first window read through the information and click the next button.
- In the next window, select the radio button “Yes, export the private key” and then click the next button.
- Select Export Extended Properties, and click next
- Set a password for the .PFX file you want to create#
- Choose a path and export the .pfx file
Now import it into the “Trusted Root Certification Authorities” that you can see in Certificate Manager
- Expand Trusted Root Certification Authorities –> right-click Certificates –> All Tasks –> Import.
- Select the file you just exported. Note that you may need to change the file type to Personal Information Exchange.
- Click Next, Fill in your file’s password, and complete the import.
That should be it completed.
An alternative to export the cert:
Copy the Thumbprint of the cert in your Powershell window.
$pwd = ConvertTo-SecureString -String "" -Face -AsPlainText
Export-PfxCertificate -cert cert:\localMachine\my\#Thumbprint# -FilePath #FilePath# -Password $pwd
Note to self: I’d a solution where Project A referenced Project B. This had been fine and stable for some time, and then suddenly intellisence started warning that the namespace I needed from B was missing, and that I was missing a project reference. Except I wasn’t. And the solution would build without fault.
I found suggestions of deleting /obj and /.vs folders – which I did – but the fix came from turning off Lightweight Solution Loading. See : https://developercommunity.visualstudio.com/content/problem/98484/project-references-do-not-work.html
Clear Visual Studio bug.
Following up my last post about Troy Hunt and breached passwords, I thought I’d look at something it mentioned – zxcvbn password strength estimation. Password strength estimators are, as a rule, crap. Usually it’s simply “is there a number, is there a capital”, etc., so passwords like “P@ssword1234” can come out as being ‘strong’, which is clearly wrong.
zxcvbn (awful name) attempts to make a smarter estimate of password strength. Basically, it looks at your password, and tries to estimate its strength based on appearances in dictionaries, structure, and entropy. It’ll then give an estimated “time to crack”, and tell you any matches that were achieved. For example (and neither of these are good passwords – score goes up to 4, and you want to get at least 3):
Yup, that’s pretty cool.
It’s available as a Nuget package (and is implemented in some form in most frameworks). The original zxcvbn was intended to run solely within the browser – but it still had a 0.5 Mb of dictionary files to download. That’s built into the assembly for the Nuget.
Testing a password – that’s simple:
var result = Zxcvbn.MatchPassword(“Squeamish Ossifrage”);
Neat. Worth considering if you’re implementing a password change or registration feature.
Bonus observation: http://gavinmiller.io/2016/a-tale-of-security-gone-wrong/
Troy Hunt has published the hashes of 306,000,000 passwords that have been breached. And exposed it as a web service.
This lets you tell a user if a given password has appeared in a breach. You send the service a hash of the password, and Troy’s web service responds if that hash has appeared in a breach.
Why is that useful? You can pro-actively inform users if their password has been breached (and recorded in haveibeenpawned) at either registration or login. You may want to block users from using that password, or you could just warn them.
Continue reading “Check Users Passwords during Registration/Login”
Yesterday, I had a working development site suddenly start throwing SSL errors:
The error message was:
This server could not prove that it is [Server Name] its security certificate is from [missing_subjectAltName]
Huh? What broke this?
Well, it turns out that Chrome had updated to Chrome 58, which removed support for the “Common Name” field. Instead, we’re supposed to use the “Subject Alternative Name” (SAN) field. That’s unfortunate; the IIS ‘Create Certificate Request‘ option we’d used resulted in a certificate with no Subject Alternative Name field. That could be a result of how it was handled – I didn’t create the certificate – but it looks like Windows MakeCert doesn’t handle Subject Alternative Names, so I wouldn’t be surprised if this is a general Windows issue.
The SSL cert continued to work without a SAN just fine in IE, but Firefox and Chrome now demand it, and so were throwing SSL errors.
Now, it seems that the Subject Alternative Name is what we’re actually supposed to use, and that publicly trusted certs have used both fields for years – but in our development server, using our own CA, that wasn’t the case.
See How to Request a Certificate With a Custom Subject Alternative Name.
Or Create a self-signed certificate for development.