Skip to content

Latest commit

 

History

History
213 lines (161 loc) · 7.26 KB

README.md

File metadata and controls

213 lines (161 loc) · 7.26 KB
Raw

TLS-O-MATIC.COM

Automated self-tests of TLS. Set up for the #MoreCrypto /#MeraKrypto Meetup in Stockholm in March 2015.

Tests 1-17 are tests of certificate validation.

Test 20 is based on recommendations from bettercrypto.org on how to configure Apache HTTPD for a strong server. Test 21 is a test of weak crypto. An application that wants to claim to be secure today should not connect to a server configured like this. Test 22 is focusing on modern Perfect Forward Secrecy encryption.

Test 30-32 are of elliptic curve certificates

Note that this repository will always be ahead of the web site. I test stuff here, then publish on the web site.

The main site is at http://www.tls-o-matic.com

About the scripts

These scripts allow you to make certificates for test purposes. The certificates will all share a common CA root so that everyone running these scripts can have interoperable certificates. WARNING - these certificates are totally insecure and are for test purposes only.

Things to go through before and during tests

- What is CN - Common Name
- What is SubjectAltName
- What is SNI - server name indication
- What about all the other stuff in the cert?
- Selfsigned certificates, CA signed certs - DV, EV

Certificate and CA Tests

  1. Describe CA, download CA cert

  2. Wrong certificate - bad CN

  3. Wrong cert - bad SubjAltName

  4. Wildcard cert

  5. Cert from future

  6. Expired certificate

  7. Evil unknown CA

  8. Client cert required

  9. Weak certificate - small key, MD5 signature

  10. Intermediate cert

  11. Long certificate chain (3 intermediaries)

  12. Huge certificate with a lot of subject alt names (21 kb cert)

  13. Certificate based on a very large key with SHA512 checksum

  14. Certificate with a weird combination of usage bits.

  15. TLS SNI test. One server, multiple certificates. Check which certificate you get from the server. The client indicates support for TLS SNI.

  16. Test of International domain names in certificates SAN certificate with IDNA names. One server, one cert with many names If you click through, you will get more test links on the result page.

    Note: Github's URL parser doesn't parse URL's with international characters as URL's and create clickable links. Bug.

  17. Test of SAN. The server name is in the Common Name but not in the SAN. If there is a list of SAN entries, a client should not check the common name. This test should fail.

  18. Test of wildcard rules.

    • coming -

  19. Test of wildcard rules.

    • coming -

Crypto and SSL/TLS protocol tests

  1. Not a certificate test. This server has no SSLv2 or SSLv3 and only supports strong crypto algorithms. Based on recommendations from http://bettercrypto.org

  2. Not a certificate test. This server has only SSLv2 or SSLv3 and only supports weak crypto algorithms. Based on recommendations from Netscape Communication in the 90's. Good old times are here again. Browsers does not accept cert or crypto.

  3. This server follows Ivan Ristic's configuration in this blog: http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html It is configured without RC4 support. Old clients will not be able to connect.

Elliptic Curve certificate and key tests

  1. The CA certificate in this test is using Elliptic Curve Key exchange instead of RSA, as is the classical key pair technology used for certificates. The server use RSA key pair, so this is a hybrid certificate - a CA with Elliptic curve and a server with RSA.

  2. This is another hybrid certificate - a CA using RSA keys and a server using elliptic curve technology.

  3. This server and CA both use elliptic curve technology. Non-hybrid, pure elliptic curve

Possible future cert tests

- Cert used for HTTP with no subject CN and only http URI's as sAN names
- Site with incomplete or bad intermediate cert chain
- Unknown extension in cert, marked critical (browser should reject)
- weak-wildcard certs ( CN="*" )  (DSL)
- Wrong version certificates - Cert version 0x01 (v2) or 0x03 (v4) certificates. Not sure if v4 should be invalid as that makes your test broken in the future, sometime. (DSL)
- MD5 intermediate in chain (invalid) (DSL)
- 1024 bit intermediate in chain (invalid) (DSL)
- Two certificates in a chain with the same serial number (invalid) (DSL)
- Issuer mismatch in the chain ( RFC 5280, Section 6.1.3) (DSL)
- cert for IP address, not host name. What is the expected outcome? CA/Browser forum doesn't like it.
- cert with null in host name

Other TLS test ideas

- Site that only offers null crypto
- Build the three reference profiles from Mozilla
  https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations

API tests (ideas)

- Possibly add a json payload in return for javascript/app testing
- Possibly add a XML payload in return for app testing

Feedback and bugs

Please use the Github bug tracker. By reporting issues you help us. It's not for support though. If you think a mailing list or some kind of forum is a good idea - please let us know!

https://github.com/edvinanet/tls-o-matic/issues

  • Don't use reserved ports - use high ports (@sindarina on Twitter)

Installing

You can install this on your own system - check out in /usr/local/tls-o-matic To test another domain you can change domain in the Makefile. Not sure if this works in all scripts yet.

Credits

  • Olle E. Johansson created the tests and the scripts
  • Many participants at SIPit helped with the original SIP tests
  • Jakob Schlyter provided good feedback
  • D Spindel Ljungmark contributed new test ideas
  • Tomas Gustavsson, Primekey for some new ideas and feedback

Contacting us

info@edvina.net http://edvina.net