I am a big fan of the idea behind Certificate Transparency [1]. The real problem with SSL (and TLS... it really doesnt matter for this discussion) is not the weak ciphers or subtle issues with algorithms (yes, you should still fix it), but the certificate authority trust model. It has been too easy in the past to obtain a fraudulent certificate [2]. There was little accountability when it came to certificate authorities issuing test certificates, or just messing up, and validating the wrong user for a domain based on web application bugs or social engineering [3][4].

With certificate transparency, participating certificate authorities will publish all certificates they issue in a log. The log is public, so you can search if someone received a certificate for a domain name you manage.

You can search certificate transparency logs published by various CAs directly, or you can use one of the search engines that already collect the logs and use them to search [1].

For example, here is an interesting certificate for sans.org" />

So what is the dark side part?

Many organizations obtain certificates for internal host names that they do not necessarily want to be known. In the past, internet wide scans did catalog TLS certificates, but they only indexed certificates on publicly reachable sites. With certificate transparency, names may leak that are intended for internal use only. Here are a few interesting CNs I found:

vpn.miltonsandfordwines.comupstest2.managehr.commail.backup-technology.co.uk

To find these, I just searched one of the Certificate Transparancy Log search engine, crt.sh , for internal.

There are currently two options considered to fix this problem:

- Allow customers to opt out of having their certificate logged. This is a bad idea. Malicious customer would certainly opt out.

- Redact sub-domain information from the log. This is currently in the works, but the current standard doesnt support this yet. In the long run, this appears to be a better option.

But you should certainly regularly search certificate transparency logs (or any scans for SSL certificates) for your domain name to detect abuse or leakage of internal information.

[1]https://www.certificate-transparency.org
[2]https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html
[3]http://oalmanna.blogspot.ro/2016/03/startssl-domain-validation.html
[4]https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html
[5]https://censys.io/certificates/1ceea0c068af62faa2974de81f8f7ba6973bb0186e3856bd1ae2c80633cdb3a1

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

Enlarge / FTC Chief Technologist Lorrie Cranor speaking at PasswordsCon 2016, part of the Bsides security conference in Las Vegas.

Shortly after Carnegie Mellon University professor Lorrie Cranor became chief technologist at the Federal Trade Commission in January, she was surprised by an official agency tweet that echoed some oft-repeated security advice. It read: "Encourage your loved ones to change passwords often, making them long, strong, and unique." Cranor wasted no time challenging it.

The reasoning behind the advice is that an organization's network may have attackers inside who have yet to be discovered. Frequent password changes lock them out. But to a university professor who focuses on security, Cranor found the advice problematic for a couple of reasons. For one, a growing body of research suggests that frequent password changes make security worse. As if repeating advice that's based more on superstition than hard data wasn't bad enough, the tweet was even more annoying because all six of the government passwords she used had to be changed every 60 days.

"I saw this tweet and I said, 'Why is it that the FTC is going around telling everyone to change their passwords?'" she said during a keynote speech at the BSides security conference in Las Vegas. "I went to the social media people and asked them that and they said, 'Well, it must be good advice because at the FTC we change our passwords every 60 days."

Read 8 remaining paragraphs | Comments

 
Cross-Site Scripting in Uji Countdown WordPress Plugin
 
HP Release Control Software CVE-2016-1999 Remote Code Execution Vulnerability
 
Cross-Site Scripting in WangGuard WordPress Plugin
 
WinSaber - Unquoted Service Path Privilege Escalation
 
Zoll ePCR v2.6.4 iOS - Multiple Persistent Vulnerabilities
 
Docebo LMS 6.9 - (Moxie) API Calls RST Remote Code Execution Vulnerability
 
Car CMS v3.00.30 - Search Cross Site Scripting Vulnerability
 
Guppy CMS v5.01.03 - Client Side Cross Site Scripting Web Vulnerability
 
FortiManager (Series) - Multiple Web Vulnerabilities
 
OpenStack Cinder And Nova Information Disclosure Vulnerability
 
OpenStack Compute (Nova) 'imagebackend.py' Incomplete Fix Information Disclosure Vulnerability
 
[security bulletin] HPSBGN03564 rev.2 - HPE Release Control using Java Deserialization, Remote Code Execution
 
Internet Storm Center Infocon Status