PKI Consortium blog

Posts by tag MITM

    2015 – Looking Back, Moving Forward
    January 6, 2015 by Bruce Morton (Entrust) Apple Attack CA/Browser Forum CAA Chrome Code Signing EV Firefox Forward Secrecy Google IETF Malware Microsoft MITM Mozilla OpenSSL PKI Policy RSA SHA1 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3 Vulnerability
    Looking Back at 2014 End of 1024-Bit Security In 2014, the SSL industry moved to issuing a minimum security of 2048-bit RSA certificates. Keys smaller than 2048 are no longer allowed in server certificates. In addition, Microsoft and Mozilla started to remove 1024-bit roots from their certificate stores. Hopefully, the key size change will support users through to 2030. Push to Perfect Forward Secrecy Following the Edward Snowden revelations of pervasive surveillance, there was a big push to configure web servers to support Perfect Forward Secrecy.

    What To Do When You Rely on Internal Names in TLS/SSL Certificates
    July 18, 2014 by Wayne Thayer Attack CA/Browser Forum Firefox IANA ICANN Microsoft MITM Qualified SSL/TLS
    A deadline set by the CA/Browser Forum for the use of Internal Names is quickly approaching, and many system administrators need to understand how best to adapt to this change. At the same time, hundreds of new top-level domains are being launched, which redefines what constitutes an Internal Name. In this post we’ll explain what the changes are, why they’re being made, and how you can update your systems in response to the problem.

    Certificate Reputation
    March 28, 2014 by Bruce Morton (Entrust) Microsoft MITM OCSP PKI SSL/TLS
    One of the advantages of having multiple certification authorities (CAs) from which to choose an SSL certificate is that customers have flexibility to choose a CA that meets their specific needs, or even use a number of CAs for redundancy or to have access to a broader toolset. The disadvantage for end users, however, is that they often may not know if a particular CA was authorized to issue the certificate, and there could be a chance that the certificate was fraudulently obtained.

    Bogus SSL Certificates
    February 20, 2014 by Bruce Morton (Entrust) Attack Google MITM SSL/TLS
    Netcraft has published an article stating they have found many bogus SSL certificates. In this case, a bogus certificate is self-signed (i.e., not issued from a legitimate certification authority) and replicates an SSL certificate of a large, popular website. This type of bogus SSL certificate could be used for a man-in-the-middle (MITM) attack. In this scenario, the attacker needs to gain a position that will allow them to intercept traffic and make you to go to their site instead of the real site.

    Intermediate CA Certificates and Their Potential For Misuse For Man-In-The-Middle Attacks
    January 9, 2014 by Robin Alden (Sectigo) Attack Firefox Google MITM Policy Root Program SSL/TLS Vulnerability
    We have seen recently that Google detected that publicly trusted TLS/(SSL) certificates had been created for Google domains without having been requested by Google themselves. The existence of such certificates might usually be taken as an indication of misissuance by the issuing CA (i.e. a failure or mistake by the CA which allowed the issuance of an end-entity certificate otherwise than in accordance with their policy) or as an indication of compromise of the issuing CA.

    2014 – Looking Back, Moving Forward
    January 6, 2014 by Bruce Morton (Entrust) Attack BEAST CA/Browser Forum CAA Code Signing ECC Encryption Forward Secrecy HSTS ICANN IETF Microsoft MITM Mozilla PKI Policy RC4 RSA SHA1 SSL/TLS TLS 1.2
    Looking Back at 2013 Protocol Attacks The year started with a couple of SSL/TLS protocol attacks: Lucky Thirteen and RC4 attack. Lucky Thirteen allows the decryption of sensitive information, such as passwords and cookies, when using the CBC-mode cipher suite. Lucky Thirteen can be mitigated by implementing software patches or preferring the cipher suite RC4. That being said, RC4 was also attacked, where through 16 million sessions a small amount of plaintext can be recovered.

    ICANN’s Accelerated gTLD Delegation Process and How This Impacts Your Organization
    December 18, 2013 by Jeremy Rowley Announcement CA/Browser Forum CASC ICANN MITM Mozilla PKI Policy Qualified Revocation SSL/TLS Vulnerability
    After the CASC’s previous letter addressing ICANN’s proposal to delegate nearly 2000 new gTLDs for use on the public Internet, ICANN identified and initiated an extensive study on two significant security issues. Now, based on the conclusions of the studies, ICANN is moving forward quickly with the delegation process, delegating more than 30 in the last two months alone. With ICANN ramping up the delegation process, nearly all 2000 will be delegated under the new rules, with only .

    Getting the Most Out of SSL Part 3: Optimization
    July 29, 2013 by Rick Andrews, Ryan Hurst MITM Mixed Content SSL/TLS
    To get the most out of SSL/TLS, you need to do a bit more than just configure your web server with an SSL certificate. The information below will help you optimize your website’s use of SSL. Making the changes suggested below will also help move your site towards “Always On SSL” (https://otalliance.org/resources/AOSSL/index.html), a best practice in which you serve the entire contents of your website over SSL/TLS. Changes to the content of your website Some HTML tags can include attributes that are links or paths to other pages on your site.

    The Importance of Checking for Certificate Revocation
    March 9, 2013 by Rick Andrews Attack CRL Identity Malware MITM OCSP Revocation SSL/TLS
    Certificates are typically valid for one to three years, and during that time it’s possible that the web site owner or the CA realizes that end users should not trust the certificate. There are several cases in which this might happen, including these: The web site owner ceases doing business, no longer owns the domain name used in the certificate, has changed their organization name, or wishes to shut down the web server.

    Participate in our community discussions and/or join the consortium