Posts Tagged ‘Microsoft’

Android SSL Problems

Thursday, November 1st, 2012 | Bruce Morton

There have been a lot of articles written recently about the problems Android applications are having with SSL, which were recently reported by German university researchers. My issue? Nobody is telling the users what to do about the problems.

This reminded me of a discussion I had where it was stated Android to iOS today is like PC to Mac.

In the old days, Apple came out with the Macintosh. It had a GUI and Apple provided the hardware, operating system and most of the applications. At the same time, Microsoft had DOS and then Windows. The Microsoft operating systems were designed to work on a PC. The PCs were made by many manufacturers. Microsoft had their own applications, but so did many other vendors.

In the end, the openness of the PC model was better and largely accepted in the market. This also made the PC a target to attack; it was a larger target and the openness dropped the level of security.

In today’s mobile era, Apple introduced the iPhone. Apple provides the hardware, operating system and some applications. It looks like Apple has improved their process as they have many other suppliers also providing applications. Apple has more developer rules, so the applications need to meet certain criteria to be made available through the App Store.

Conversely, Android is an open-source project with Google playing the key role. The hardware that uses Android is made by many suppliers. The applications are wide open to many suppliers and appear to have fewer criteria to be made suitable for use on Android. With this model, it looks very much like the PC model — and Android is steadily gaining market share because of it. This open model allows the applications to do things that they can’t do on the more closed iOS platform.

All this to say, there are some security problems with Android applications. So what did we expect? If the controls are low, how do we expect high quality?

What should users do? These phones can do some cool stuff. You can talk with them, send emails, browse the Web and use thousands of applications. But who says the cool stuff is secure? I’m sure there is much more developer time invested in coolness than security.

Users are advised to be careful when using mobile device for anything where security needs to be a priority. Users should:

  • Use different passwords for each application
  • Don’t use applications for secure needs unless they have been reviewed and approved (either corporately or by a trusted security researcher)

Along with the above advice, users should secure their mobile device by doing the following:

  • Have the mobile automatically lock and require an unlock passcode
  • Review and adjust application privacy settings
  • Review location and data sharing permissions
  • Be careful what links you click
  • Enable remote locking, wiping and tracking of devices
  • Do not jailbreak or root your device as a large percentage of malicious applications can only run on these types of devices

Certificate Key Lengths: Bigger is Better

Friday, September 7th, 2012 | Scott Shetler

As previously discussed,  Microsoft issued a security advisory announcing they will block keys that are less than 1024 bits long. This feature will appear in an update for supported versions of Microsoft Windows (not affecting Windows 8 or Windows Server 2012; the functionality is already there) and, of course, you have to upgrade to this version for this feature to activate.

What is the impact to you? Possibly nothing. Even 1024-bit keys are not recommended anymore, especially over larger 2048-bit keys. In fact, 1024-bit keys currently cannot be signed with end dates greater than December 31, 2013, for publicly trusted certificates. As a result, 1024-bit keys are also going the way of the dodo, albeit a couple of years behind.

However, if you do have keys sizes smaller than 1024 bits in your environment, they will not be recognized on Windows machines with this update applied, potentially breaking an application or causing an outage. And even if you don’t apply the update on your application server for example, that doesn’t mean you won’t suffer — browsers who apply the patch will not be allowed to access sites with small key sizes, effectively breaking your site anyways.

Microsoft recommends four methods of discovering small RSA key sizes in your environment:

  • Check certificates and certification paths manually
  • Use CAPI2 logging
  • Check certificate templates
  • Enable logging on computers that have the update installed

Here’s another idea: use an automated certificate discovery tool to scan your hosts/ports and CAPI stores and build an inventory upon which you can then set policy alerts when key sizes don’t meet your policy.

Microsoft to ban keys less than 1024 bits

Friday, June 15th, 2012 | Bruce Morton

For those of you who do not maintain the size of your keys for digital certificates, you’re about to have some problems. Microsoft is not a proponent of small-sized digital keys. Their Windows Root Certificate Program does not allow CAs to issue certificates with keys less than 1024-bit RSA and deprecates keys that are less than 2048-bits RSA. This is in line with the NIST recommendations to move to a minimum of 2048-bit keys by January 1, 2014, and also with the CA/B Forum Baseline Requirements with the same specification.

In August 2012, Microsoft will introduce a new patch to the following operating systems: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2. The update will block the usage of cryptographic keys that are less than 1024 bits. The result will introduce problems when going to an SSL site, enrolling a certificate, creating or consuming S/MIME email messages, installing Active X controls, or installing software where a small cryptographic key has been used.

If you only have publicly-trusted certificates from reputable vendors, there’s nothing to worry about. Public CAs, such as Entrust, do not issue certificates with small keys and have plans in place to move to a minimum of 2048-bit keys by January 1, 2014.

However, if you are like most organizations we talk to, you likely have certificates signed by various CAs. Some users may have problems, come August, if their certificates have been issued from an internal CA that does not follow the common certificate policy rules.

Entrust does offer a solution called Discovery, which helps you inventory all your digital certificates, from any vendor or source, and set policy regarding key size. With Discovery, you are alerted to certificates with key sizes that are outside your policy.

Why Your Browser Matters

Thursday, October 13th, 2011 | Bruce Morton

Over the past couple of weeks, the Online Trust Alliance (OTA) and Microsoft have launched campaigns promoting the use of modern browsers. OTA’s campaign, “Why Your Browser Matters,” provides tools and resources to help website operators provide user education on the value of keeping browsers current.

What appears to be complementary to the OTA campaign is the Microsoft announcement of a new website, YourBrowserMatters.org. The site evaluates the browser being used and gives you a score from 0 to 4. IE8 scores 3, Chrome 14 scores 2.5, Firefox 7 scores 2, and IE9 scores a perfect 4. Opera and Safari are not supported by the site.

Some may suspect that the scoring system is largely tilted in Microsoft’s favor. On the other hand, the campaign complements another effort by Microsoft, The IE6 Countdown, which is dedicated to dropping the usage of Microsoft’s IE6. I like the line, “Friends don’t let friends use Internet Explorer 6. And neither should acquaintances.” I suppose Microsoft is taking advantage of promoting the tight integration between Windows 7 and IE9, to provide arguably the safest Windows browsing experience

The long and short of it is that your browser does matter. The latest version is undoubtedly more secure than an older version. And yes, some browsers are better than others, but this seems to shift from time to time as browser vendors play catch up.

Personally, I have always been an IE user, but switched to Chrome when IE9 was launched. Why? I also use Windows XP which does not support IE9. My thinking was that if I wanted to stay on the latest browser version, then I would have to switch to something that continues to support XP. I wonder how Microsoft missed that subtlety.

Code Signing

Friday, June 17th, 2011 | Bruce Morton

Although this is the Entrust Insight SSL Blog, Entrust Certificate Services issues other types of certificates such as Code Signing, Adobe CDS and Client S/MIME. The purpose of this post is to kick off a series on Code Signing. When the series is completed, this post can be used as an index to all other related posts.

Here is what we plan to cover:

  1. Why Code Sign?
  2. What is Code Signing?
  3. Verifying Code Authenticity
  4. How to Digitally Code Sign
  5. Code Installation Trust Decision
  6. What is Time-Stamping?
  7. Self-Signed Versus Trusted CA Certificates
  8. Code Signing: Best Practices
  9. Application Reputation

The above list may change as the articles are written. Reader feedback would be greatly appreciated to help refine the topics.

Entrust offers Code Signing certificates to sign and certify the following:

  • Authenticode (most Microsoft® Windows® platforms)
  • Java
  • Microsoft® Office® macros and Visual Basic script

Key Size Update

Monday, January 24th, 2011 | Bruce Morton

Last summer I posted a blog about the move 2048-bit RSA keys in SSL certificates. While I was drafting my post, NIST was working on a new Special Publication. This document, just released as NIST SP 800-131A, allows a transition period to from 1024-bit to 2048-bit RSA keys. In the period of 1 January 2011 through 31 December 2013, 1024-bit keys are allowed, but their use is deprecated. In response, the industry has adjusted its policies and practices, for example:

MozillaDates for Phasing out MD5-based signatures and 1024-bit moduli

  • December 31, 2010 – All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits. Additionally, CAs with root certificates that have RSA key size smaller than 2048 bits should stop issuing intermediate and end-entity certificates from those roots.  (Note those should words used to say must.)
  • Key lengths providing 80 bits of security using approved digital signature algorithms are allowed for legacy use after 2010.
    • This means that CAs should only consider issuing a 1024-bit certificate if it is requested and justified by the subscriber for a specific reason, such as interoperability with devices that do not yet support certificates with larger key sizes.
    • The CA must assess the risk involved in issuing such a certificate for legacy use/interoperability, and determine if they are willing to accept the risk, as well as any possible liability. The subject and relying parties also need to determine if they will accept any risks and liabilities.
  • All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of 2013.

Microsoft - A Note on Implementation of the Requirement to Issue Longer Key Length Certificates

  • We based our technical requirement for migrating away from 1024-bit RSA certificates on NIST Guidance, and NIST updated it with 800-131
  • In general this means that CAs should continue to deploy stronger key length certificates, and the vast majority of CAs have already migrated to 2048-bit RSA in most scenarios; but if they must continue to issue 1024-bit RSA end-entity certificates in certain contexts (e.g. hardware, smart cards, and other devices in capable of accepting longer key lengths), those certificates should be considered “deprecated” or “restricted” according to the use of those terms, defined in the NIST document.
  • In any event, end-entity 1024-bit certificates should not expire after December 31, 2013.

Entrust has adjusted its policies and practices as well. Although 1024-bit RSA keys are highly restricted, Entrust will issue non-EV SSL certificates with 1024-bit RSA keys to a maximum validity of 31 December 2013 in support of inter-operability and backwards compatibility issues. All other certificates will continue to have a minimum key size of 2048-bit RSA.

What’s the deal with 2048-bit keys?

Wednesday, June 23rd, 2010 | Bruce Morton

Entrust has been getting a lot of questions about the move to 2048-bit RSA keys.  The move is causing some web administrators concern, so we thought it would be a good time to clarify the reasoning behind the move to 2048-bit keys.

The US National Institute of Standards and Technology (NIST) prepared a special report SP 800-57 in 2005 for comment.  The updated report SP 800-57 in March 2007 Part 1 and subsequent reports Part 2 and Part 3, laid the foundation for how application developers and certification authorities would manage key sizes for digital certificates such as those used for SSL/TLS, code signing, and document signing. The recommendation was that 1024-bit RSA keys should only be depended on until 31 December 2010, after which the minimum key size should be 2048-bit RSA.  This recommendation has been adopted and published by a number of organizations:

Adobe CDS Certificate Policy

  • CDS Subordinate CAs shall use an RSA key pair with at least 2048 bits.
  • CDS Subscriber certificates shall use an RSA key pair with at least 2048 bits.

CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates

  • Requires a minimum of 2048-bit RSA keys for Root and Subordinate CAs.
  • Requires a minimum of 1024-bit RSA keys for end entity certificates and 2048-bit keys for end entity certificates that expire after 31 December 2010.

Microsoft Certificate Root Program

  • All new Root certificates must have a minimum be 2048-bit RSA keys.
  • 1024-bit Roots will be removed from the Microsoft Root Certificate Program by 31 December 2010.
  • All end entity certificates issued after 31 December must have a minimum of 2048-bit RSA keys.

Mozilla Foundation dates for phasing out MD5-based signatures and 1024-bit moduli

  • December 31, 2010 – CAs must stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs must stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root.
  • December 31, 2013 – Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits.

The reason for moving to stronger subscriber keys is to protect the data of Subscribers and Relying Parties.  Cryptanalytic attacks against a particular key size become more practical as computing power increases and new techniques are developed.  See, for instance, 768-bit RSA key in December 2009.  A broken end-entity key could expose encrypted session data or allow a man-in-the-middle attack.

Entrust has been proactive in adopting the standards and recommendations. Entrust has put in restrictions that all certificates issued after 2010 have a minimum of 2048-bit RSA keys. In addition Entrust is actively moving to 2048-bit root certificates. As times move forward, we will keep our eyes on the technology and the standards and implement policy to protect our subscribers and relying parties.

Updated January 24, 2011: Here is a Key size update post based on the release of NIST Special Publication 800-131A.