As you all hopefully know by now, Microsoft released a security update that disallow the use of RSA keys with a key lenght below 1024 bits. And now there is a new important security advisor from MS with news on certificates in the platform.
This time they are issuing a recommendation to discontinue the use of SHA-1 as a hash algorithm in certificates. SHA-1 was published in 1995 and as we all know, a lot of things have happend in the IT industry since then. And considering that NIST recommended to move away from SHA-1 as early as 2005 we probably should have done this a long time ago. But as a matter of fact, up to 98% of the certificates in use today uses SHA-1 tells us that is not the case.
So how will this security advisory impact us? Well nothing will happen right away, it will take a couple of years before MS will stop the use of these certificates. But the SHA-1 deprecation policy says the following:
Will apply to Windows Vista and later, and Windows Server 2008 and later. (All supported OS)
CAs must stop issuing new SHA-1 SSL and Code Signing certs by 1 January 2016.
Windows will stop accepting SHA-1 end entity certificates by 1 january 2017. This means that all valid SHA-1 SSL certificates must be replaced at this date.
Code Signing Certificates
After 1 January 2016 Windows will stop accepting SHA-1 code signing certificates. But there will be an exception. If the signed code have a time stamp it will still be accepted until further notice. So the first step is to make sure that all code from now on should be time stamped when signed. And then you should issue a new code signing cert with SHA-2 as soon as possible.
Microsoft Root Certificate Program
Members in the Root Certificate Program will not be allowed to issue certificates using the SHA-1 hashing algoritm for the purpose of SSL and code signing after January 1 2016
MS Security Advisory 2880823 (http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2880823-recommendation-to-discontinue-use-of-sha-1.aspx)
The effect on Microsoft Root Certificate Program. (http://technet.microsoft.com/en-us/security/advisory/2880823)
Memento: When exporting a root certificate (with its private key) from a Microsoft Root CA you get a pkcs#12-file (.pfx). In order to import this cert and key into the Cisco Ironport WSA as a root certificate you need to do this:
- Move the .pfx-file to a machine with openssl installed
- Run “openssl pkcs12 -in myinfile.pfx -out myoutfile.pem -nodes
- When prompted enter the password you used when exporting the cert/key on the CA server.
- Open the myoutfile.pem file in a texteditor.
- Copy the lines beginning with (and including!) the line “—–BEGIN CERTIFICATE—–” and until the end of the line “—–END CERTIFICATE—–”.
- Paste that content to a new file and save it to something like cert.pem
- Open the myoutfile.pem again in a text editor.
- Copy the lines beginning with line “—–BEGIN RSA PRIVATE KEY—–” and ending with the line “—–END RSA PRIVATE KEY—–”.
- Paste the content to a new file and save it to something like key.pem.
- Select the files as Certificate and Key respective in the WSA GUI under Security Services-HTTPS Proxy-Edit Settings…-Root Certificate for signing-Use Generated Certificate and Key.
I have googled this so many times now. Hopefully google will index this rapidly and next time I google it I will see my own blog post as the first search result.
Memento is… oh sorry, forgot what to write here…
After reading about sqrl, the qr-based login system invented by Steve Gibson, I started to think about hashed password generators as a light-variant to sqrl.
What if you could have a password generator that always gives you the same output? Think about it. You use the generator that outputs the password of “1LKk23j!2323^dfD” to be used at facebook.com. One year later you forgot that password and you start the same password generator and it gives you the same password again. Great, huh?
In order for it to be secure we have a few requirements though:
- It needs to be unique per site. That is, I do not want to use the same password on facebook, twitter, amazon and instagram.
- It needs to be unique per user. I do not want to have the same facebook password as you have.
So, we take 2 inputs to the password generator:
- Something that is unique per site. The domain name or the site name or whatever. For simplicity say that you enter “facebook” for facebook, “twitter” for twitter and so on.
- Something that is unique per user. My super secret key. It might be the chassis number of my ex spouse brother´s first car, the first sentence in your favourite book or anything hat you will always remember (and write down, and store it securely!).
We also have to decide the length of the output passwords. I suggest something like 12 characters. It is long enough to not brute force.
I built the password generator as a simple bash script since I have already openssl installed. The script below will do this:
- ask for the site-specific parameter you want to create the password for (in our example ‘facebook)
- Ask for your super secret private password.
- Create a cryptocraphic hash digest of your site-specific password ‘facebook’ with your private key as a… eeeh… private key.
- Since the output is binary, all non-printable characters will be removed.
- The first 12 bytes of the string will be printed on the screen.
read -rp "site: " PARAMETER
read -rsp "common private key: " PASSWORD
echo "Password for site $PARAMETER:"
echo "$PARAMETER" \
| openssl dgst -sha512 -binary -hmac "$PASSWORD" \
| tr -cd '[:print:]' \
| cut -c1-12
IANAC (I am not a cryptographer). Not at all. Am I doing this wrong? Can I enhance the security even further? If you have any input in the subject, please write a comment below!
As I wrote above, I did come up with the idea when reading about sqrl. And after googling around the interwebz I quickly realised that all good ideas are already had. The script above is a rip-off of the hashapass cli-version with some improvements. Since I am not using base64 but instead binary output I will get a password with more variety in characters (higher entropy). Also I raised the password length from 8 to 12 characters.
Issue: Your internal clients tries to reach an internal server but since they resolves the address of the server from an external DNS-server they will get a public IP.
Solution: DNS Doctoring.
In the example below your client is on the internal 192.168.1.0/24-network. When looking up the hostname for the webserver www.domain.com it resolves to the public ip of 18.104.22.168. When the client on the inside tries to reach the NAT:ed IP 22.214.171.124 the ASA will get confused and there will be no response.
There is a NAT already configured mapping the public ip 126.96.36.199 to the internal IP 192.168.1.10. The trick here is to add the keyword “dns” to the end of the static NAT-statement. This will inspect all DNS-traffic goingthru the ASA and when it seed a DNS-response of 188.8.131.52 sent to an internal host it will modify the packet so that the response will be 192.168.1.10 from the clients point of view.
The only thing to remember here is that you need to do DNS inspection in the firewall for this to work. Or else it will not.
So the configuration will be:
object network web server
nat (inside,outside) static 184.108.40.206 dns
If you are a GUI-type of human you set the DNS-setting by finding your specific NAT-statement (for the public webserver) under Configuration -> Firewall -> NAT-rules and in the window for your NAT hit the “Advance”-button. There you find the “Translate DNS replies for rule”.
The inspection is found under Configuration -> Service Policy rules -> Global Policy -> inspection_default (double click it) -> Rule Actions -> Protocol Inspection and make sure that the DNS checkbox is set.
And don´t you forget to write mem!