A Hardware Security Module (HSM) is a crypto appliance for securing encryption keys (and other kind of secrets). And it´s available as a service in Azure which is really cool. Ok, we have to admit that Amazon was first with this kind of service. But Azure Key Vault seems like a smarter implementations with a much nicer price-tag.
So how can we use this feature? One example is to store encryption keys. Let´s say you got a web-server in Azure and got a public certificate for that web-service. Then you can store the encryption keys in the Key Vault instead of in the file system of the server. Another example is to encrypt a SQL-server using the SQL Server Connector for Key Vault. Or you can simply deploy an encrypted virtual machine with the CloundLink SecureVM and store the master key in the Key Vault.
What other nice things is there? The Key Vault uses FIPS 140-2 level 2 validated HSM from Thales and Common Criteria EAL4+ certification is pending for the HSM´s which is really nice, and you get the option to establish Vaults in multiple Azure Datacenters to make it globally redundant. And it seems possible to sync with an existing, internal HSM farm as well.
So now we are (finally) talking about some really cool Azure functions! And I must admit that I missed that it was in preview, even though I´ve heard whispers about it for a long time. But if you are into security and encryption you should definitely have a look!
More info can be found on the Azure site and on The Official Azure Key Vault Team Blog.
It´s time to look into migration from SHA1 as signing algorithm for your certificates. The obvious reason is security and SHA1 have been considered insecure for at least 10 years by now. And in late 2013 Microsoft announced their SHA1 deprecation policy.
What does this actually mean then?
Code-signing certificates won´t be accepted in Microsoft products after January 1 2016 unless it got a timestamp. Then it will be ok until 14 January 2020.
For SSL certificates, Microsoft products will stop accepting SHA1 end-entity certificates by 1 January 2017. And all SSL certificates valid after that date needs to be signed with a SHA2 algorithm.
Google (Chrome) and Mozilla (Firefox) is on this as well and info can be found here:
Digicert have a really nice SHA2 compatibility list:
What have to be done?
Publicly signed certificates are in most cases signed with SHA2, but check to make sure. If you have SHA1 signed SSL-certificates valid after January 1 2017 all vendors I know of will re-sign the cert with SHA2. Contact the issuer for help.
Internally signed certificates have to be re-issued as well. First you have to prepare the CA to use SHA2 and then you will need to start to replace your certificates.
Are you unsure of your certificates? Test your site here: https://www.ssllabs.com/ssltest/index.html
Any questions? Just let me know!
Is it possible to provide certificates to industrial equipment that doesn’t have any enrollment capabilities?
That´s the challenge one of our customers gave us a couple of weeks ago. The certificates should be used for network access on an 802.1x network and authentication to a database. Me and my fantastic colleague Tomas accepted the challenge and went to work.
So we had to create a completely automatic enrollment process with as little user interaction as possible. Our goal was to provide the manufacturer with password protected pfx-files in a bulk with a password file, mapping the pfx-files to a randomly generated password for each pfx. First we started by doing a manual enrollment process.
Enrollment process – step by step
- The first step was to create an inf-file (request.inf) as input to the request file.
Subject = CN=Test123.trustmyroot.com
Exportable = True
KeyLength = 4096
KeySpec = 1 ; AT_KEYEXCHANGE
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True ; The key belongs to the local computer account
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
SMIME = False
- After that we used the inf-file together with certreq.exe to create a certificate request file.
Certreq.exe -new d:\request.inf d:\enroll\req\Test123.req
- The next step was to submit the request file to the CA and issue a certificate with certreq.exe.
Certreq.exe -submit -config “SRV001.trustmyroot.com\CA01” d:\enroll\req\Test123.req d:\enroll\cer\Test123.cer
- After that we imported the certificate to the certificate store on the local machine with certutil.exe
Certutil.exe -addstore -f MY d:\enroll\cer\Test123.cer
- Then we had to match the certificate to the private key so we would be able to export the pfx-file.
Certutil.exe -repairstore MY Test123.trustmyroot.com
- Next step was to export the pfx from the certificate store and set a password for the private key.
Certutil.exe -password 1q2w3e4r -exportPFX Test123.trustmyroot.com d:\enroll\pfx\Test123.pfx
- Then we deleted the certificate and private key from the local certificate store
certutil –privatekey –delstore MY Test123
After testing this process we gave it all to our brilliant colleague Simon, which created a powershell script with some parameters, a password generator and some other nice stuff.
After testing and handover to the customer they were extremely happy with the solution and it works perfect!
Thought I´d write a short blog post about public certificates for test environments. By public certificates I mean certificates issued by an external CA and trusted by most platforms.
If you got a test or lab environment and want to publish an external service with SSL, for example ADFS, you need a certificate. This certificate must be trusted by all devices used by consumers of the service. OK, it´s a test environment so you can use you own CA to issue the certificates and import the RootCA certificate on all devices you are testing with. But I guess a lot of you out there isn´t that into certificate that you find that especially interesting. 🙂
So what are your options? You can of course buy a SSL cert from Digicert, Verisign or any other public CA. But I guess you don´t want to spend too much money on your testing. And there is another alternative.
Try StartSSL.com (no, I´m not getting paid for this!). They are using the StarCom Class 1 CA and issues free SSL certificates. And the best part is that the CA is trusted by almost every platform no the market.
All you need to do is to create an account and you´re on! There are of course some restrictions. For example you can´t issue SAN (Subject Alt Name) certs for free, the validity period is only 1 year, no EV certs for free for example. But If you just are using it for test/lab your fine! (And I rebuild my test environment a couple of times a years so I don´t see any real drawbacks!
A comparison chart of their certificates can be found here: http://www.startssl.com/?app=40
Well, that´s all for now folks! 🙂
Time for the next big security flaw! This time Googles Security Team have discovered a vulenerability in SSL 3.0 and the list of targets is huge. All implementations of SSL 3.0 is vulnerable for attacks and the recommended to disable SSL 3.0 as soon as possible. (As a mather of fact, SSL 3.0 is over 15 years old, and for obvious reasons already outdated. But it´s still widely spread for compability reasons.)
But there is a lot of factors that makes an attack less likely. For example a “man-in-the-middle” to exploit, in most cases Java have to be enabled on the client side and if someone tries to attack you the can take control of your sessions, but not steal your password.
A test to see if your browser is vulnerable can be done here: https://www.poodletest.com/
A newly discovered zero-day vulnerability called Sandworm have been published today by iSight (http://www.isightpartners.com/2014/10/cve-2014-4114/). The vulnerability affects all supported versions of Windows and is set to critical.
Attacks using the vulnerability have been seen on Nato, Power and Telecom companies, Western European governments and US academic organizations. All discovered attacks have been traced back to cyber-espionage out of Russia.
A short summary:
- An exposed dangerous method vulnerability exists in the OLE package manager in Microsoft Windows and Server
- Impacting all versions of the Windows operating system from Vista SP2 to Windows 8.1
- Impacting Windows Server versions 2008 and 2012
- When exploited, the vulnerability allows an attacker to remotely execute arbitrary code
- The vulnerability exists because Windows allows the OLE packager (packager.dll) to download and execute INF files. In the case of the observed exploit, specifically when handling Microsoft PowerPoint files, the packagers allows a Package OLE object to reference arbitrary external files, such as INF files, from untrusted sources.
- This will cause the referenced files to be downloaded in the case of INF files, to be executed with specific commands
- An attacker can exploit this vulnerability to execute arbitrary code but will need a specifically crafted file and use social engineering methods (observed in this campaign) to convince a user to open it
The properties of the effected file from Windows 8.1
According to information, Microsoft will release a patch for this vulnerability today (MS14-060). And as a part of the security bulletin Microsoft will describe a list of workarounds to the vulnerability. These workarounds should help mitigate the risk of exploitation while the patching process unfolds.
More information can be found at Isights web site: http://www.isightpartners.com/2014/10/cve-2014-4114/