# Welcome to mTLS Workshop! 👋 # → --- # Using the slides * Use your ← → (left right) arrow keys to navigate between the slides * Use your ↑ ↓ (up down) arrow keys to navigate to sub-slides * Use ESC to switch between the overview mode ---- # Sub-slide You found a hidden message. 😉 --- # A bit of theory 📚️ ↓ ---- ### OSI Model | Layer | Name | Example | | ---- | ----- | -------- | | 1 | Physical | Ethernet, Bluetooth | | 2 | Data Link | Ethernet frames | | 3 | Network | IP, ARP | | 4 | Transport | TCP, UDP | | 5 | Session | RPC, SQL, NFS | | 6 | Presentation | SSL, tls | | 7 | Application | HTTP, DNS, SMTP | ---- ## TCP 3-way handshake ```sequence Client->Server: SYN Server->Client: SYN-ACK Client->Server: ACK ``` ---- # SSL/tls  --- ## Prerequisites https://gitlab.com/olegfiksel/mtls_workshop_froscon2020 Pre-flight check ``` curl \ -v \ --cacert ./certs/ca.crt \ --cert ./certs/client.crt \ --key ./certs/client.key \ https://mtls-workshop.fiksel.info:13370 ``` --- # ⚠ Warning ⚠ Please don't use `nmap` on the test server because cloud providers can detect port scans and blacklist your IP --- ## Get ready This workshop will guide you through a series of quests. Each quest will encourage you to establish a connection to the given endpoint and troubleshoot issues on your way. At the end of each quest you will get a conclusion, revealing the issue. Try to get to the ground of the issue by yourself using the tools described in the prerequisites section. --- # Warm-up 🏃 Try to connect to this service https://mtls-workshop.fiksel.info:13371 ``` Slide down *** *** ********* ******* ***** *** * ``` ---- # Hint * Use netcat to connect to the server * Use tcpdump to capture the traffic ↓ Another hint ---- # Another hint Is a firewall blocking the connection or is it a problem with the service? ---- ## Expected result TCP 3-way-handshake cannot be established. ### netcat ``` nc -vvv mtls-workshop.fiksel.info 13371 nc: connectx to mtls-workshop.fiksel.info port 13371 (tcp) failed: Operation timed out ``` ### tcpdump ``` IP 192.168.0.111.52480 > 3.120.126.88.13371: Flags [S], seq 310466095, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 38592978 ecr 0,sackOK,eol], length 0 IP 192.168.0.111.52480 > 3.120.126.88.13371: Flags [S], seq 310466095, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 38593380 ecr 0,sackOK,eol], length 0 IP 192.168.0.111.52480 > 3.120.126.88.13371: Flags [S], seq 310466095, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 38593526 ecr 0,sackOK,eol], length 0 ``` ---- ## Conclusion With high probability a firewall is blocking the connection because packets are dropped and not rejected. Firewalls normally don't spend ressources to send back a TCP RST packet. They, normally, just ignore your packets. That's where TCP timeout comes from. ### Links * [TCP 3-way-handshake](https://wiki.wireshark.org/TCP_3_way_handshaking) ---- # Well done! # 🎉 Next quest → --- # Another warmup 🏃 Try to connect to this service https://mtls-workshop.fiksel.info:13372 ↓ Hint ---- # Hint * Use netcat to connect * Use tcpdump to capture the traffic ↓ Another hint ---- # Another hint * Why the connection is being closed? ---- ## Expected result Connection refused ### netcat ``` nc -vvv mtls-workshop.fiksel.info 13372 nc: connectx to mtls-workshop.fiksel.info port 13372 (tcp) failed: Connection refused ``` ### tcpdump ``` 192.168.0.111.55156 > 3.120.126.88.13372: Flags [S] 3.120.126.88.13372 > 192.168.0.111.55156: Flags [R.] ``` ---- ## Conclusion There seem no firewall blocking our TCP connection but the server actively refuses the connection. The OS will send TCP RST packet back to the client if no service is listening on this port. ---- # Well done! # 🎉 Next quest → --- ## First quest You know what to do 😉 https://mtls-workshop.fiksel.info:13373 ↓ Hint ---- # Hint * Use curl to make the connection while using Wireshark to capture the traffic * You can filter the traffic before capture using a simple filter * `host mtls-workshop.fiksel.info` ↓ Another hint ---- # Another hint * What is this HTTP packet doing here? ---- ## Expected result ### curl ``` curl -v https://mtls-workshop.fiksel.info:13373 ... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number * Closing connection 0 ``` ### Wireshark  ---- # Conclusion Seem that we are trying to establish a tls (HTTPs) connection and the server answers HTTP. Our client is assuming it's going to get a "binary" tls handshake but gets some garbage (HTTP) and can't establish a tls connection. As a result our client terminates the connection. ---- # Well done! # 🎉 Next quest → --- ## Second quest https://mtls-workshop.fiksel.info:13374 ↓ Hint ---- # Hint * Use curl to make the connection while using Wireshark to capture the traffic ↓ Another hint ---- # Another hint * Probably your (current) curl version doesn't support the old tls protocol, the server is using. * Try some older curl version (from Ubuntu 16.04) ---- ## Expected result ### curl (without SSLv3 support) ``` curl https://mtls-workshop.fiksel.info:13374 curl: (35) error:1400510A:SSL routines:CONNECT_CR_SRVR_HELLO:wrong ssl version ``` ### curl (with SSLv3 support) ``` curl -3 -vk https://mtls-workshop.fiksel.info:13374/ ... * SSL connection using SSL3.0 / RSA_AES_128_CBC_SHA1 ... ``` ↓ Wireshark ---- ## Expected result ### Wireshark  ---- ### Conclusion The server supports only SSLv3.0, which is vulnerable (POODLE) and is not supported by the majority of the new clients. The best way to figure it out is to get a traffic capture and look at the client and server hello mesages. We should see the client sending tls 1.X hello and the server a SSL3.0 hello. #### Links * https://de.wikipedia.org/wiki/Poodle ---- # Well done! # 🎉 Next quest → --- # Third quest https://mtls-workshop.fiksel.info:13375 ↓ Hint ---- # Hint * If you can't astablish a tls connection try using a newer curl version (Ubuntu 18.04) * Try using `openssl s_client` to check the tls connection parameters ---- ## Expected result ### curl with gnutls (Ubuntu 16.04) ``` curl -vk https://mtls-workshop.fiksel.info:13375 ... * gnutls_handshake() failed: Handshake failed ``` ### curl with openssl (Ubuntu 18.04) ``` curl -vk https://mtls-workshop.fiksel.info:13375 ... * SSL connection using TLSv1.2 / AES128-SHA256 ``` ↓ Wireshark ---- ### Wireshark  ---- ### Conclusion Let's look at the cipher negotiation method (use your traffic capture): * The client sends its ciphers in the client hello * The server doesn't send its ciphers. It uses the client's list to find a common cipher. * If the server doesn't find a common cipher it terminates the tls handshake If no common cipher can be found it's not transparent to the client why the tls handshake is terminated. ---- # Well done! # 🎉 Next quest → --- # Fourth quest https://mtls-workshop.fiksel.info:13376 ↓ Hint ---- # Hint Use curl to send the client certificate. ---- ## Expected result ### curl ``` curl -v --cacert ./ca.crt --cert ./client.crt --key ./client.key https://mtls-workshop.fiksel.info:13376 ... Redirecting to https://letsencrypt.org ``` ---- ### Conclusion If a server needs a client cert authentication (mutual-tls) it, sometimes, sends a certificate request together in a `server hello` also specifying the CA(s) it will use for client certificate verification. ↓ Wireshark ---- ###### Wireshark  ---- # Well done! # 🎉 Next quest → --- # Fifth quest https://mtls-workshop.fiksel.info:13377 ↓ Hint ---- # Hint * Use curl to send a client certificate to the server * Read the HTTP body to get futher hints ↓ Another hint ---- # Another hint Seem that the server want's to have "Roger Rabbit" somewhere in the certificate [DN](https://docs.oracle.com/cd/E24191_01/common/tutorials/authz_cert_attributes.html#p_authz_cert_attributes_overview). ↓ Another hint ---- # Another hint The current certificate will not be accepted. You have to create a new certificate with "Roger Rabbit" in any of the certificate field. Because you have the CA and the private key you can do it. ↓ Solution ---- # Solution Create new private key ``` openssl genrsa -out client2.key ``` Create certificate request ``` openssl req -new -key client2.key -out client2.csr ``` Sign the request to create the new certificate ``` openssl x509 -req -in client2.csr -CA ca.crt -CAkey ca.key -set_serial 101 -extensions client -days 365 -outform PEM -out client.crt ``` ---- ## Expected result ###### curl ``` curl -v --cacert ./ca.crt --cert ./client2.crt --key ./client2.key https://mtls-workshop.fiksel.info:13377 ... < HTTP/1.1 301 TLS Redirect ``` ---- ### Conclusion Sometimes it's not enough for a server to verify if a client certificate is signed by a certain CA. Here comes certificate fields validation on the server side pretty usefull. There are [better](https://en.wikipedia.org/wiki/OAuth) athorization methods out there. ---- # Well done! # 🎉 # 🏁 → --- # Congratulations! # 🏆️