1. President Obama forgets to renew SSL certificate

    At the start of the first US Government shutdown since 1996, an SSL certificate used on barackobama.com has expired. Issued by Go Daddy in September 2012, the SSL certificate for *.barackobama.com and barackobama.com was used by Organizing for Action, a non-profit grassroots organisation aligned with Obama's political policies. Whilst not directly associated with the US Government, the expiry of the SSL certificate for barackobama.com during a US Government shutdown is nonetheless a curious coincidence.

    Warning in Google Chrome when visiting a website using the SSL certificate for *.barackobama.com.

    Several SSL certificates controlled by the US Government expired today and are still being used — for example, the SSL certificates used on both ui.tn.gov and webmail.coop-uspto.gov have expired and may not be replaced any time soon. Furthermore, there are at least 30 US Government sites still using SSL certificates that are scheduled to expire before Friday.

    SSL certificates expiring may be least of the problems for US Government websites, some websites have been taken offline: www.nasa.gov now redirects to notice.usa.gov.

    Posted by Robert Duncan on 1st October, 2013 in Around the Net, Security

  2. Wildcard EV certificates supported by major browsers

    Extended Validation, or EV, certificates are designed to provide evidence of a greater level of verification by the Certificate Authority of the legal identity of the company in control of the SSL certificate and domain name. By way of contrast, the most common type of certificate, domain-validated, only requires the CA to verify control of the domain name. Browsers display EV-specific cues within the user interface to highlight this additional verification: most notably, the company name is displayed in the address bar, often with a green padlock or a green bar.

    An Extended Validation certificate for login.live.com in Google Chrome

    EV certificates are subject to additional requirements, over and above those specified in the Baseline Requirements. As with the Baseline Requirements, the EV guidelines were drawn up by the CA/B forum, an industry group of both browser vendors and CAs. The EV guidelines prohibit EV certificates from using wildcards (i.e. www.example.com, mail.example.com, and paypal.example.com would all match *.example.com) and explicitly mention this restriction twice "Wildcard certificates are not allowed for EV Certificates".

    Nevertheless, Verizon Business has chosen to test browsers' approach to wildcard EV certificates by issuing a certificate to Accenture for *.cclearning.accenture.com. Verizon Business — which is not a member of the CA/B forum — is known for its maverick approach to certificate issuance having issued certificates (including EV certificates) which violate the Baseline Requirements.

    Despite the EV guidelines prohibiting wildcard EV certificate issuance, presently most major browsers fail to enforce this restriction. Google Chrome, Firefox, Internet Explorer, Opera, and Safari (Desktop) all retain the EV browser cues when visiting a website using this EV certificate.

    Clockwise from top left: Google Chrome, Internet Explorer, Opera, and Firefox. All display the conventional EV browser cues.

    The only exception was Safari — Desktop Safari displays the EV browser cues as normal, as do the remainder of the desktop browsers; however, Safari on iOS 7 does not display the EV UI.

    Safari (Desktop)

    Safari on iOS 7 does not display the conventional EV UI for the wildcard EV certificate. An example of the EV UI in iOS 7.

    Netcraft offers a Baseline Requirements checking service for CAs to provide third-party verification of Baseline Requirements conformance. For more information contact sales@netcraft.com

    Posted by Robert Duncan on 26th September, 2013 in Security

  3. Certificate Authorities struggle to comply with Baseline Requirements

    SSL Certificate Authorities (CAs) are responsible for issuing the SSL certificates which are used to protect billions of secure transactions across the internet against eavesdroppers and impersonators. The CA/B forum — a group of CAs and browser vendors — drew up the Baseline Requirements in 2011 outlining a set of minimum standards to which all CAs should operate.

    Since the "effective date" of the document, 1st July 2012, compliance with the Baseline Requirements has been mixed — Netcraft has previously discovered non-compliant certificates, including short RSA public keys and irrevocable certificates. More than a year on and several months after Mozilla incorporated the Baseline Requirements into its CA policy (albeit with a transition period allowed) CAs are still issuing non-compliant certificates.

    By examining the certificates found in Netcraft's SSL Survey and evaluating them against a small subset of rules extracted from the Baseline Requirements document, Netcraft found more than 2,500 non-compliant certificates. The non-complaint certificates fall into one or more of the categories described below: some of the problems are serious security vulnerabilities, and others are less critical but are still violations of the Baseline Requirements.

    • Short RSA public key — the shorter a public key is; the easier it is for an attacker (such as the NSA) to brute-force the secret private key, and hence decrypt communication. NIST recommended that certificates should not use RSA public keys shorter than 2048 bits after December 2013 and the CA/B forum imposes the same rule.
    • Missing OCSP URL — OCSP is one of the two available revocation mechanisms available to CAs to disable the certificate after it has been issued. As web-browser support for certificate revocation varies, non-EV certificates without an OCSP URL are effectively irrevocable in Firefox. Without the ability to revoke certificates, if the certificate were ever to be compromised — by criminals or government agencies — it could be used for up to five years. The Baseline Requirements do allow certificates to omit the OCSP URL if and only if they are used on "high traffic" websites and the website staples the OCSP response to the TLS handshake — none of the websites with missing OCSP URLs highlighted here did so.
    • SAN extension — the Baseline Requirements document discourages the use of the Subject Common Name field to contain the hostname for which the certificate is valid. Instead, the Subject Alternative Name extension should be used and it must contain at least one record. Additionally, any hostname in the Subject CN field must also be duplicated in the SAN extension — a multi-domain certificate intended for www1.example.com and www2.example.com must contain both in the SAN extension and at most one in the Subject CN (for backwards compatibility).
    • Validity Period — as of the effective date, the Baseline Requirements limit the maximum validity period of a certificate to 5 years (60 months). Whilst exceeding this validity period constraint isn't itself a security problem it slows downs the pace of change within the industry — with a shorter maximum validity period, browsers can rely on legacy behaviour disappearing and can remove insecure functionality more rapidly.

    A short key warning for a 512-bit certificate in Google Chrome. This type of warning is proposed to be applied to certificates violating the maximum validity period.

    Several large CAs have issued non-compliant certificates since July 2013, a year after the original deadline, including Symantec, Go Daddy, and Verizon Business.

    • Symantec — a BMW certificate issued by TC Trust Center (a Symantec company) is missing an OCSP URL and does not include a stapled OCSP response, making it irrevocable in Firefox. An SSL certificate used for online banking was issued by VeriSign on August 2nd 2013 without the required SAN extension.
    • Verizon Business — a certificate issued by Etisalat (a UAE-based telecoms provider which operates a Verizon Business signed sub-CA) for ADCO, an onshore oil drilling company, violates a number of Baseline Requirements: it has a short RSA key valid after 31st December 2013, it has no OCSP URL and it does not have the mandatory SAN extension. Etisalat has previously been associated with SSL interception. Cybertrust, operated directly by Verizon Business, has also issued more than its fair share of non-compliant certificates including certificates belonging to Target [Short Key, no OCSP URL], the US Dept. for Homeland Security [no SAN, no OCSP URL], and American Express [an EV certificate without an OCSP URL!]. A number of other sub-CAs signed by Verizon Business have issued non-compliant certificates including Microsoft [missing SAN, no OCSP URL] and Vodafone [missing SAN].
    • SwissSign — Nestlé, a customer of SwissSign with its own intermediate certificate, has issued non-compliant certificates including: those missing SAN records and OCSP URLs.
    • Go Daddy — a significant number of Go Daddy certificates exceed the maximum permitted validity period of 5 years. These certificates are likely "re-issued" (the meaning of which is debated by Google, see below) and otherwise do not obviously violate the Baseline Requirements. Go Daddy have proposed a modification to the Baseline Requirements to allow such re-issued certificates to be exempt from maximum validity period constraints.

    Google Chrome, in the first quarter of 2014, will reject all certificates issued after the effective date, 1st July 2012, which violate the maximum validity period (60 months). A number of CAs have issued such certificates, often as part of a re-issuance process, which Google deems to be non-compliant with the Baseline Requirements.

    In the September 2013 SSL Survey, using the criteria from the proposed Google Chrome patch, Netcraft found 3,243 certificates which will be considered invalid in Google Chrome as a result of this change. Go Daddy issued over three-quarters of these certificates (2,498) and Comodo also issued a significant number (606). The longest-lived non-compliant certificate issued by a member of the CA/B Forum and discovered by the SSL Survey has a validity period of over 82 months.

    Furthermore, Google's technical enforcement is set to get tougher: Ryan Sleevi has stated that certificates with short public keys – that is, RSA public keys shorter than 2048 bits expiring after 31st December 2013 are “next up” on Google’s list. Google's proposal to use the original July 2012 date as a threshold for enforcement isn't popular with some of the CAs in the CA/B forum: GlobalSign and Comodo have argued that such technical constraints should only be enforced for certificates issued after the announcement.

    Despite Google's aggressive stance, many of Google's own certificates did not comply with some of the Baseline Requirements: in the September 2013 Netcraft SSL survey, almost 500 Google certificates did not contain a URL to an OCSP responder or include a stapled OCSP response (making the certificates irrevocable in Firefox). Since the survey ran in mid-August, a large number of Google's certificates have been replaced and now contain an OCSP URL, but a few non-compliant certificates are still in use including one on Zagat.com. The Zagat.com certificate also has an incomplete SAN record (it does not contain the hostname from the Subject Common Name field).

    Posted by Robert Duncan on 23rd September, 2013 in Security

  4. Perfect Forward Secrecy in the Netcraft Extension

    Netcraft has added a Perfect Forward Secrecy (PFS) indicator to the Netcraft Extension for Firefox, Chrome and Opera. This lets users see which websites would allow encrypted traffic to be decrypted en mass at a later date if the site's private key were to be compromised — a danger previously highlighted by Netcraft in June.

    PFS, when implemented correctly, ensures that if the long-term private key of a site served over SSL is compromised, historical encrypted traffic cannot be decrypted in bulk. Instead, an eavesdropper would have to break each individual connection independently, which would be incredibly time consuming.

    With the recent revelations from Edward Snowden that the NSA is able to read encrypted internet traffic, PFS support is very desirable for privacy-conscious internet users, particularly in countries that also have key disclosure laws.

    Currently, most of the major web browsers make it difficult to tell whether or not a website supports PFS. For example, Chrome, Opera 15, and Internet Explorer display information about the current cipher suite in a pop-up, but checking for PFS support relies on in-depth knowledge. Firefox and Opera 12 display part of the cipher suite in their user interfaces; however, they crucially lack the key exchange mechanism, which means it is not possible for the user to tell whether the site supports PFS. Safari fares the worst, as it does not display any information at all about the current cipher suite.

    The Netcraft Extension — which blocks phishing attacks and displays metadata about visited websites — now clearly indicates whether the site you are visiting supports PFS. This is displayed in the user interface as a green tick if the site supports PFS, and a red cross if it does not. In addition, in both Chrome and Opera, a small indicator is displayed beside the Netcraft badge when visiting an SSL site which does not support PFS.

    The following screenshots show the PFS indicator in the Netcraft Extension when visiting the DuckDuckGo search engine, which enabled the use of PFS cipher suites after the lack of PFS was highlighted in Netcraft's previous analysis of PFS support.

    PFS indicator in the Netcraft Extension for Google Chrome™
    (The Opera version looks similar)

    PFS indicator in the Netcraft Extension for Firefox

    The Netcraft Extension is available for Firefox, Chrome and Opera, and can be downloaded from toolbar.netcraft.com. More information about the PFS indicator can be found on the Netcraft Extension FAQ page.

    Note: The new version of the Firefox extension is currently awaiting approval from Mozilla; however, it can be manually installed from the version history page by selecting version 1.8.1.

    Posted by Graham Edgecombe on 6th September, 2013 in Security

  5. Deceptive domain and SSL certificate issued by Network Solutions

    Network Solutions allowed a fraudster to register a deceptive domain name earlier this week: secure-chaseonline.com. Network Solutions also issued a valid SSL certificate for the domain, which was used for a phishing attack which targeted customers of Chase Bank.

    Phishing attack targeting Chase bank on secure-chaseonline.com

    The phishing site added further credibility to the attack by using an encrypted HTTPS connection. The fraudster obtained a domain-validated SSL certificate from Network Solutions, and, as with the domain, it was valid for one year from 3rd September 2013.

    The SSL certificate used on secure-chaseonline.com

    Although opportunities were missed to prevent the suspicious domain name being registered and the corresponding SSL certificate being issued, the certificate used by the site does at least support OCSP, which can allow the issuer to instantly revoke the certificate. However, the efficacy of this mechanism largely depends on which browser the victim is using, and how it has been configured. For example, Firefox — which does performs OCSP checks by default — will only display content from https://secure-chaseonline.com if the certificate has not been revoked. Google Chrome, on the other hand, does not perform such checks by default (for non-EV certificates).

    However, as Network Solutions was also the registrar of the domain, it would have been more effective to simply suspend the domain, which is what appears to have happened yesterday:

    No match for "SECURE-CHASEONLINE.COM".
    >>> Last update of whois database: Thu, 05 Sep 2013 12:56:58 UTC <<<
    

    The fraudulent SSL certificate was later revoked — the certificate's serial number can be found on Network Solutions' certificate revocation list at http://crl.netsolssl.com/NetworkSolutionsDVServerCA.crl

    The CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates [PDF] says that certificate authorities SHALL subject high risk requests — which includes names at high risk of being used in a phishing attack — to further scrutiny prior to issuance. Netcraft's Domain Registration Risk service is ideal for both domain registrars and certificate authorities, as it judges the likelihood of a new domain being used for fraudulent activities. It identifies domains which are deceptively similar to legitimate websites run by banks and other institutions that are commonly targeted by phishing attackers.

    While some phishing attacks can be identified prior to domain registration or SSL certificate issuance (such as the one described above), a significant proportion of phishing attacks make use of compromised web sites (often exploiting vulnerabilities in commonly deployed software platforms, such as WordPress). Netcraft can alert registries, SSL certificate authorities, or registrars and hosting companies of phishing sites discovered using their infrastructure to conduct a phishing attack.

    Please get in touch (sales@netcraft.com) if you would like to try out this service or for subscription information.

    Posted by Paul Mutton on 6th September, 2013 in Security

  6. Free domains put Mali back on the map – for phishing

    When the African nation of Mali announced that it was going to provide free .ml domains from July, their goal was to put Mali back on the map. It appears they have now succeeded, but perhaps not in the way they had intended — thanks to the free domains, Mali now has the most phishy top-level domain of any country in the world.

    Nearly 6% of the .ml domains in Netcraft's survey are currently blocked for hosting phishing sites, making it by far the phishiest TLD. In comparison, the second most phishy TLD, .bt (Bhutan), has only 0.7% of its sites blocked for phishing.

    .ml domains can be quickly and easily registered at Freenom, which is owned by the Netherlands-based Freedom Registry. Registrants are required to create an account with a valid email address, and a CAPTCHA is used to try and prevent automated registrations. Domains can be registered for between 1 and 12 months initially, with an unlimited number of renewals. Domains which contain more than 3 characters are free.

    It is not surprising to see free domain names being used in phishing attacks, but some TLDs have managed to tackle such fraud with astounding efficacy. The .tk TLD was taken advantage of extensively by phishers in 2011, prompting its registrar, Dot TK (another subsidiary of Freedom Registry), to introduce an anti-abuse API to allow trusted partners to shut down sites that use the .tk ccTLD. This dramatically reduced the average uptime of phishing sites which used .tk domains, making it a less attractive platform for fraudsters. Indeed, .tk does not even appear within the top 50 phishiest TLDs today; however, considering .tk and .ml share the same owner, this makes it somewhat surprising to see .ml being so heavily abused already.


    A Taobao (Chinese shopping site) phish using a .ml domain, hosted in the US.

    Despite the obvious appeal of a free and easily registered domain name when orchestrating a phishing attack, the phishiest TLDs are not always free, nor easy to register. Back in June, Morocco had the phishiest TLD (.ma), although it has since fallen to 12th place. As well as not being free, the administrative contact for an .ma domain must be established in Morocco; however, people living outside Morocco can still register an .ma domain through third parties.

    Netcraft provides services to help protect domain registries, brand owners and hosting companies. You can also protect yourself against the latest phishing attacks by installing Netcraft's Anti-Phishing Extension and help protect the internet community by reporting potential phishing sites to Netcraft by email to scam@netcraft.com or at http://toolbar.netcraft.com/report_url

    Posted by Paul Mutton on 5th September, 2013 in Domains, Security

Page 4 of 55« First...23456102030...Last »