Overview of how ssltest.offenseindepth.com operated when it was alive.

gistfile1.txt

- Apache configured to accept SSL on a number of ports, each with their own cert demonstrating an individual test case.
- ELBs performing PAT so I had :443 on a number of IPs ending up hitting apache on it's various ports.
- PHP on the webserver would parse the Host Header, and return a response setting a corresponding div to vulnerable
- When the main domain name was accessed, it would instead return a bunch of DIV's each named to correspond to a given vuln, and including the CSS file (generated by PHP above) to test for cert validation.

The end result of all this was a table that looked like the ones shown near the end of;
http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

Tested included;
- Mismatched CN
- Unknown CA
- Self-Signed Certificate
- Expired Certificate
- Basic Constraints flaw (intermediate has CA=FALSE)
- Revoked Certificates
- Certificate with a Null character, that only matched DNS if the Null acted as a terminator.

The Null Char test was somewhat unique.  I couldn't find a CA that would issue these (good!) so I made one under a private CA.  You had to trust that CA, or there was no chance of it validating.

The Expired cert I got from a 30-day trial through some CA or another.  I just waited 30 days..

The rest I got from startssl.com.  I used one of their valid leaf-node certs as an intermediate in testing the Basic Constaints issues, and issued a revocation request for one (They actually asked me why I was requesting revocation on a cert named revoked.offenseindepth.com, hehe).

So the flow was something like this

browser request --> main site --> table of issues w/ CSS includes

Each include spawned;
browser request --> ELB:443 --> Apache:xxxxx 
Apache:xxxx --> malformed cert --> browser

If the browser accepted the cert, it'd flag the vuln.  Otherwise, the CSS load failed and there was no change.  

User interaction (accepting warnings, etc..) can obviously influence the load/no-load, but if the user rejects all warnings or isn't prompted, the results reflect the browser's issues.

In my case, I was really testing interception proxies, so I'd first test the browser directly hitting the site, then switch to proxy through an interception proxy which re-wrote certs under a private CA the browser trusted.  Any difference showed the influence of the proxy's server-side validation routines.