Bruce Morton

CAs Support Standards and Regulations

Friday, May 17th, 2013 | Bruce Morton

This post was originally published on the CA Security Council blog.

There is an industry myth that certification authorities (CAs) are not regulated. In fact publicly-trusted SSL CAs support the development of industry regulations and have been audited annually to ensure compliance to the many requirements.

To provide some history, SSL CAs have always self-policed themselves by having external audits performed. In the ‘90s, the CAs wrote certificate policies and certification practice statements requiring annual compliance audits. Since there were no CA audit criteria, the CAs contracted for SAS 70 audits.

In 2000, the AICPA and CICA developed the WebTrust for CA audit criteria. The CAs switched to being audited to meet the WebTrust criteria and many browsers required successful WebTrust for CA audits to maintain root certificates embedded in their software.

In 2005, the CAs and the browsers combined to form the CA/Browser Forum. The purpose was to improve the issuance and management of SSL certificates. The first release was the Extended Validation (EV) SSL certificate requirements and in 2007, the issuing CAs were audited in accordance with the WebTrust for EV criteria.

However, the EV criteria did not cover standards for non- EV certificates. The CA/Browser Forum addressed this problem by developing the Baseline Requirements for SSL certificates. In 2012, the CAs started issuing certificates meeting the Baseline Requirements and in 2013 those CAs will be audited to the SSL Baseline Audit criteria, which was also developed by WebTrust personnel.

Now, when SSL CAs display their audit results, expect to see WebTrust for CA, WebTrust for EV and Baseline Requirements reports.

In addition to improving the CA certificate issuance and management standards, the CA/Browser forum has also introduced Network and Certificate System Security Guidelines which is hoped to be added to the audit criteria in the future. Also the European Telecommunications Standards Institute (ETSI) has adopted the CA audit criteria and has updated their standards.

For more information on SSL CA audits and other standards that help regulate the industry, please see the CASC whitepaper.

Bruce Morton

Could be Problems with New gTLDs

Tuesday, May 14th, 2013 | Bruce Morton

The PayPal information risk management team warns that the introduction of new generic top-level domains, or gTLDs, could impact security.Generic Top Level Domains

For many years it has been common for enterprises to configure DNS domains with suffixes that are not in the set of public TLDs. The practice has been recommended by software vendors and security experts. The public delegation of these suffixes as new gTLDs will impose serous security risks on unprepared systems and roaming enterprise laptops.

Domains to be concerned are the top-10 invalid queries from the ICANN SAC 045 report, plus those gTLD suffixes identified in RFC 6762 for Multicast DNS. They are: belkin, corp, domain, home, internal, intranet, invalid, lan, local, localdomain, localhost, private and wpad.

The CAs are particularly concerned with .corp. This suffix is proposed as a new gTLD that is most often used by CA customers. If .corp is approved as a new gTLD, then correcting its use in an enterprise will have the greatest cost; and not correcting will carry the greatest risk.

Any domains that are approved as new gTLDs will have to be addressed by the CAs. The CAs will have to review the certificates they have issued and advise customers that have certificates with a new gTLD. The customers will then have to register their domain. If the customer cannot or does not register the domain, then the CA must revoke the certificates within 120 days from the gTLD being approved, as required in the CA/Browser Forum Baseline Requirements.

If you have certificates that use a proposed new gTLD, then please take precautions. You will have to make plans to either register the domain, change to a domain that you already have registered, or obtain your certificate from a non-publicly trusted CA.

Image Source:

http://news.dot-nxt.com/sites/news.dot-nxt.com/files/gtld-letterpress-s.jpg

Bruce Morton

Firefox to Block Mixed Content

Thursday, May 2nd, 2013 | Bruce Morton

Congratulations, Mozilla, on your plan to release Firefox 23 that will block mixed content.

Website owners who have mixed-content pages will surely be impacted and should make changes. Along with Firefox, Internet Explorer, Chrome and Opera already block mixed content. This means the users of the site will get trust warnings or the browser’s security indication (i.e., lock icon) may not be present.

What is Mixed Content?

Mixed content is presenting an SSL secured webpage with content (e.g., JavaScript files, images, CSS files) that is not transmitted over SSL. The insecure content makes the page insecure. An active man-in-the-middle (MITM) attack can piggyback on the unprotected resource and hijack the user session.

Firefox 23 blocks mixed active content and changes the security display for mixed passive content. Firefox graphics for mixed content can be seen in the Mozilla post.

Mixed Active Content

Mixed active content can change the behavior of the HTTPS webpage and potentially steal sensitive data from the browser user. A MITM attacker can intercept requests for the HTTP active content, re-write the response, and perform actions such as: steal login credentials, acquire sensitive user information or install malware on a user’s system.

When Firefox 23 sees active content (e.g., JavaScript, CSS, objects, xhr requests, iframes and fonts) it will block the request from the HTTPS page.

Mixed Passive Content

Mixed passive content has limited effect on the HTTPS website. The attacker could replace an image with an image of inappropriate material or inappropriate information to the user. The attacker would not have the ability to impact the rest of the webpage.

However, the attacker could watch the images or other information such as the headers and the cookies. If the image is served from the same domain as the main webpage, then the HTTPS protection becomes useless.

When Firefox 23 sees passive content (e.g., images, audio and video loads) then it will block the passive content by default, but will change the security display of the page by not showing the lock icon.

How Does a Website Operator Fix the Problem?

First, be careful as to what you link to your webpage. Do you own or control the content? If not, I would consider not allowing any third-party mixed content.

For content that you own or control, please protect it with an SSL certificate. If you cannot protect with SSL, then do not link to that content.

Bruce Morton

SSL Fingerprints

Wednesday, April 17th, 2013 | Bruce Morton

Are your secure SSL communications being compromised by a man-in-the-middle (MITM) attack?

This issue came up when it was discovered that TURKTRUST issued an unauthorized certification authority (CA) certificate. When the CA certificate was installed on a Check Point firewall configured for inspection, it allowed the firewall to clone certificates for any given Internet website. When an enterprise user tried to contact a secure site, the firewall cloned a certificate for that site. This allowed the enterprise to proxy the SSL communications and gave them the ability to inspect what was being communicated.

A similar issue was also recently reported when it was discovered that Nokia was performing MITM to help compress data and speed up loading of Web pages on some of its phones. Opera Mini and BlackBerry also perform MITM. However, these companies openly state their process.

An enterprise may also want to perform MITM. In the past, most traffic was HTTP — no security. This allowed the enterprise to monitor traffic and try to ensure its intellectual property was not being exposed and that users were not performing in a manner which could harm the enterprise. However, as sites have added security with HTTPS, it was harder to monitor the traffic. The enterprise still wants to know what is being communicated as it is responsible for the actions of its users.

The enterprise can discover what is being communicated by proxying SSL communications. This is done by installing an HTTPS proxy appliance and creating a CA certificate. In order to do this, they must first install the CA certificate on the workstations in the enterprise. Then, when an end-user goes to a secure site, the HTTPS proxy creates its own clone certificate for the website that is signed by the private key that signed the enterprise’s CA certificate. As the workstations already trust the CA certificate, the SSL connection is established without a trust message.

How do you know if your enterprise is proxying your SSL communications?

GRC has created HTTPS Fingerprints. This service allows you to check whether or not your enterprise is performing MITM on the SSL secured site that you are trying to reach. It compares the certificate fingerprint to what you would receive to the fingerprint that they receive by going direct. If they are the same, the certificate is authentic and you have no problem. If they are different, then it is likely that someone is performing MITM on your SSL connection.

I say likely because if you find a difference they could be generated for a number of ways:

  • Your SSL communications are being proxied by your enterprise
  • You are under a legitimate MITM attack from a malicious group or hacker
  • The website you tried to reach uses multiple certificates and the one you reached does not match the one that GRC reached

If you find a difference then you need to consider reporting the problem to your IT group. If you are uncomfortable with your enterprise performing a proxy of your personnel SSL communications, consider performing those tasks at home.

Bruce Morton

Self-Signed Certificates don’t deliver Trust

Thursday, April 4th, 2013 | Bruce Morton

This post was originally published on the CA Security Council blog.

We’ve heard the argument that website operators could just use self-signed certificates. They are easy to issue and they are “free.” Before issuing self-signed certificates, it’s a good idea to examine the trust and security model. You should also compare self-signed certificates to the publicly trusted certification authority (CA) model; and then make your own decision.

Self-Signed Certificate Model

  • Owner says who they are
  • Owner issues on their own policy
  • Owner is responsible for quality
  • Owner may not follow industry guidelines
  • Owner may not provide certificate status
  • Compromised certificates may not be able to be revoked
  • Owner is not audited
  • Issuer of certificate may not be authorized by the domain owner
  • Certificates may not be renewed if there are no reminders
  • Self-signed certificate model does not provide trust and the browser provides a trust dialogue box to indicate such

Publicly-trusted CA-Signed Certificate Model

  • CA verifies the owner of the domain and the certificate applicant
  • CA operates to a policy in conformance with the requirements of the browser and operating system vendors. The requirements include the CA/Browser Forum Baseline Requirements, Extended validation (EV) Guidelines and recommendations from NIST.
  • CA provides quality to the certificate. Checks include compromised keys, minimum key size, ensuring hashing algorithms, maximum validity period and proper certificate extensions.
  • CA updates policy based on industry best practices
  • CA provides certificate status through CRL and OCSP
  • Compromised certificates can be revoked
  • CA is audited to certificate issuing criteria such as WebTrust for CA, WebTrust for EV and SSL Baseline Requirements
  • Certificate requesters for a Domain validated certificate are authorized by the owner of the domain. Requesters for Organization and Extended Validation certificates are authorized by a member of the organization specified in the certificate.
  • CAs provide multiple reminders to ensure the certificates are renewed before they expire. CAs may also provide certificate discovery tools to find certificates on your systems which may not have reminders.
  • Publicly trusted CA model is based on the CA being a trusted third party to the browser/OS vendor, the website certificate subscriber and the end-users of the website. The CA is obligated to meet the requirements of all three parties.

So, when should you use a self-signed certificate?

When trust, security, service, quality and reliability are not your criteria.

Bruce Morton

RC4, CBC, what the …?

Wednesday, March 27th, 2013 | Bruce Morton

We had the BEAST attack and it was said, “Prioritize RC4 cipher suite.”

We had the Lucky Thirteen attack and it was said again, “Prioritize RC4.”

We had the AlFBPPS attack and it was said, “RC4 is old and crummy. CBC-mode would be better, if only it wasn’t already attacked by BEAST and Lucky Thirteen. Everyone should use TLS 1.2.”

What the …?

We need to support TLS 1.2? Well, we don’t. Although it was published in 2008, browsers and servers are still readily deployed with TLS 1.2 not enabled.

Where were the guys to say, “Hey, we really don’t want to prefer outdated RC4.” Where were the guys to say, “Hey, developers, why don’t your systems support TLS 1.2, by default, out of box?”

Why are people thinking up improvements, getting them approved in standards, and then nobody mandating that they be implemented and deployed?

I wish I knew.

As we move forward, Ivan Ristić has some great recommendations for each stakeholder to consider implementing.

Bruce Morton

IETF 86 – Web PKI Working Group

Friday, March 22nd, 2013 | Bruce Morton

At the IETF 86 meeting in Orlando last week, there was a working group meeting discussing the operations of the Web PKI. At the previous IETF 85 meeting a birds-of-a-feather was held to discuss the purpose of having such a group. The result of the meeting was an established group with the charter that states purposes such as:

  • Working group will work to improve the consistency of Web security behavior
  • Address problems as seen by the end-users, certificate holders and CAs
  • Describe how the Web PKI actually works
  • Prepare documented deliverables as discussed below

The meeting discussed the charter and the four following deliverables. More information is in the presentation slides; look under the Operations and Management Area, then under WPKOPS.

Trust Models

The trust model document will discuss how the root store providers support the trust between the end entities Web server and the relying party’s browser. The CAs play a trusted third party (TTP) in the model where they comply to the root store providers certificate policy, provide certificates to the end-entities and provide certificate status to the relying parties.

What makes the case interesting is that there are many parties in each role in the model. The trust model for the Web PKI has to consolidate certificate policies from many root store providers. The trust has to work for many servers and many browsers. There are many CAs globally providing TTP to the model.

The document will discuss the basic model and the variants for how the roles are adapted to the real world.

Certificate Revocation

Certificate revocations will be reviewed to see what CAs issue, whether end-entities provide revocation data and how relying parties handle revocation.

Revocation data is provided by certificate revocation lists (CRL) and OCSP, including OCSP stapling. The distribution points for this data are included in the SSL certificate.

OCSP, as deployed, is also interesting. The group wants to know what trust anchors are accepted and what certificate extensions are set, such as key usage, extended key usage and policy OIDs.

Field & Extension Processing

With many CAs issuing certificates and many browsers and Web servers using certificates, we all want to know what is in them and how are they handled. The problem is inconsistent behavior. From a support point of view, consistent behavior is less confusing and easier to maintain user satisfaction.

To develop the document, researches are using six different user agents installed on 30 operating systems to test 300 conditions. The goal will be to use cross-sourcing to find the broad areas of matches and mismatches, then perform specific testing to focus on the confusing areas. The data will be tabulated on spreadsheets through Google Drive and made freely available to interested parties.

The project is still at the beginning where the conditions list, platforms/OSs and user agents still need to be determined.

TLS Stack Operation

There are common PKIX issues with the TLS stack, such as no chain to trust anchor, non-matching names, expired certificates and expired CA certificates.

The document will cover TLS protocol tweaks to common SSL libraries to achieve interoperability. It will address how alerts are provided to the relying party and the navigation bar use of long-lived icons and indicators. It will also discuss PKI-related choices made by the relying party.

Moving Forward

Development of the documents will take about two years to complete. Once completed, the data will help industry standard groups and developers improve the use and security of PKI implementations. Hopefully, this will translate to a more pleasant and secure browsing experience.

Bruce Morton

RC4 Attack in SSL/TLS

Tuesday, March 19th, 2013 | Bruce Morton

The team of Nadhem AlFardan, Dan BernsteinKenny Paterson, Bertram Poettering and Jacob Schuldt published an RC4 encryption attack in SSL/TLS.

As Matthew Green says, RC4 is old and crummy. The advantage is RC4 is pretty fast, requires less hardware and does not require padding such as CBC-mode. On the other hand, about 50 percent of SSL traffic uses RC4 because it was recommended to use instead of CBC due the BEAST and Lucky Thirteen attacks.

The multisession attack can only be carried out by a determined attacker who can generate sufficient sessions for the attack. Sufficient is defined as more than 16 million sessions where they can recover a limited amount of plaintext. As such, the attacks do not pose a significant danger to ordinary users of TLS in their current form. However, please remember the cryptographer’s adage: attacks always get better, they never get worse. Otherwise, fix it today, so you don’t have to fix it in the future.

The idea is the bytes coming out of the RC4 aren’t quite random-looking. They have small biases. By getting many different encryptions of the same message using different keys, the attacker can use the small deviations to figure out what was encrypted.

The research team states there are several possible countermeasures against their attacks:

  • Switch to CBC-mode ciphersuites. This is a suitable countermeasure provided previous CBC-mode attacks, such as BEAST and Lucky Thirteen, have been patched. Many implementations of TLS 1.0 and 1.1 now have patches against these attacks.
  • Switch to AEAD ciphersuites, such as AES-GCM. This is probably a future solution as support for AEAD ciphersuites is specified in TLS 1.2, which is not widely supported.
  • Patch TLS’s use of RC4. This solution is not practically deployable given the large base of legacy implementations and the lack of a facility to negotiate such a byte discarding procedure.
  • Modify browser behavior. There are ways to modify the manner in which a browser using TLS handles HTTP GET requests to make the attack less effective. However, care is needed to avoid potential future improvements to their attack.

The bottom line is the industry needs to move to TLS 1.2 and use AEAD ciphersuites.

For website operators and browser users, you need to use the common support technique. Use the latest version of your software and apply patches as they become available.

I love the team’s answer to the question, “Why doesn’t the attack have a cool name?”

Response, in Western culture, naming one’s attacks after obscure Neil Young albums is now considered passé. And I thought Zuma, Re-ac-tor or Fork in the Road would have been great attack names. For now it’s just called the AlFardan-Bernstein-Paterson-Poettering-Schuldt (AlFBPPS) attack.

Updated April 4, 2013: Opera is making changes to address the problems with RC4. Hopefully the other browsers will follow suit.

Bruce Morton

SSL Certificate Status Checking

Tuesday, March 12th, 2013 | Bruce Morton

As part of its effort to promote SSL certificate best practices, the CA Security Council (CASC) has offered a couple of blogs on the importance of revocation checking, categorized in Part 1 and Part 2.

Here are my summaries of SSL certificate status checking.

What is the purpose of a CA-issued SSL certificate?

  • To bring trust to the end-user of who controls the website
  • The CA-issued SSL certificate brings encryption as well, but so do self-signed certificates; self-signed does not bring trust
  • Trust is elevated based on the verification practice used to validate the certificate applicant:
    • Domain Validation (DV) verifies the domain name is controlled by the applicant.
    • Organization Validation (OV) verifies an identity that controls the validated domain.
    • Extended Validation (EV) verifies the identity and authorization of the applicant at a higher level.

Why revoke a certificate?

  • Changes by the website owner (e.g., no longer in business, does not own domain, changed organization name)
  • Private signing key is compromised by a third party
  • CA learns that information in the certificate has changed or has been misrepresented

How is a certificate status conveyed?

  • Certificate Revocation List (CRL) – A digitally-signed file containing a list of certificates that have been revoked and have not yet expired
  • Online Certificate Status Protocol (OCSP) – A protocol in which the client requests the status for a particular certificate signed by a particular issuer, and receives a digitally-signed response containing its status
  • CRL and OCSP responses can be found at a website address included in the certificate

What could happen if you go to a risky site?

  • Loss of Private Information – An attacker controlling the risky site could capture your personal information such as your birth date or credit card number
  • Identity Theft – An attacker could capture your username and password, allowing them to impersonate you on a website
  • Financial Loss – Loss of your credit card number or username and password could mean financial loss
  • Malware Installation – An attacker could install malware on your computer to help steal other information or take over your computer for a larger attack

How do I check certificate status?

  • Certificate-status checking is done by your browser or other certificate-aware software
  • In some cases, you may need to ensure certificate-status checking is turned on. This is more likely for software using Windows XP as an operating system.
  • Browsers and applications provide dialogue boxes to turn on certificate-status checking, see below

Windows 7

Firefox

Java

Bruce Morton

Mozilla Endorses SSL Baseline Requirements

Wednesday, February 27th, 2013 | Bruce Morton

The CA/Browser Forum Baseline Requirements have been endorsed by Mozilla and have been included in their certificate authority (CA) certificate policy.

The Baseline Requirements are an auditable set of certificate management requirements that were finalized in November 2011. Their purpose is to set a level of management requirements for all SSL certificates. The Baseline Requirements also apply to Extended Validation (EV) certificates, but EV has its own guidelines to manage stricter verification.

The members of the CA/Browser Forum made them effective as of July 1, 2012. For the most part, the major vendors of publicly-trusted SSL certificates have now been compliant for the last eight months. The audit authorities developed audit criteria and both WebTrust and ETSI have integrated the Baseline Requirements into their CA audit programs.

The final task was to have a browser vendor require the Baseline Requirements in their certificate policy. Mozilla has done that with its Mozilla CA Certificate Policy (Version 2.1), which was released on February 14, 2013.

Here is a high-level look at the changes included in the Mozilla policy update:

  • Multifactor authentication or limit domains for all accounts capable of directly causing a certificate issuance
  • Root certificates should only issue subordinate CA certificates. End-entity certificates could be issued from a root in accordance with Baseline Requirement section #12
  • All subordinate CAs must be technically constrained or publicly disclosed and audited
  • Technical constraints are performed by adding an Extended Key Usage (EKU) to the subordinate CA certificate that specifies the key usage that the CA is to be used to issue. The constrained CAs must also do the following for the specified certificate types:
    • Server authentication (SSL) – must also include a Name Constraints X.509V3 extension
    • Secure email – must issue certificates can only be issued for authorized email addresses or mailboxes
    • Code-signing certificates must issue the end entity certificates including a subject distinguished name with organization, locality (where relevant), state or province (where relevant) and country name
    • If technical constraints for a subordinate CA is not possible, then they must be audited in accordance with Mozilla’s certificate policy and must be publicly disclosed
    • CA operations and issuance of SSL certificates must be done in accordance with Baseline Requirements version 1.1

Mozilla also has more details and a set of frequently asked questions, including implementation dates. The bottom line is that all new CAs must meet the Baseline Requirements and all existing CAs must be audited to the Baseline requirements by February 15, 2014.

I would like to thank Mozilla for endorsing and requiring the Baseline Requirements.