Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevSecCon London 2018: Get rid of these TLS certificates

187 views

Published on

Paweł Krawczyk
Most network services and daemons now offer TLS transport protection and their managing certificates and TLS configuration for server farms may use more resources than actual configuration of these services. What if you could get rid of all this complexity and replace it by single transport protection protocol, securing all of the traffic between your servers trasparently and with single centralized key and configuration management? This will be a story of a successful implementation of IPSec protocols, largely and undeservedly forgotten in that purpose, for securing a farm of production cloud servers, with configuration centrally managed with Ansible.

Published in: Technology
  • Positions Available Now! We currently have several openings for writing workers. ◆◆◆ http://ishbv.com/easywriter/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

DevSecCon London 2018: Get rid of these TLS certificates

  1. 1. LONDON 18-19 OCT 2018 “Get Rid Of These TLS Certs” PAWEL KRAWCZYK
  2. 2. You?
  3. 3. # tcpdump -Xni eth0
  4. 4. # tcpdump -Xni eth0
  5. 5. # tcpdump -Xni eth0
  6. 6. Transport Security in Linux Solution Performance Authentication Configuration Availability SSH tunnel User mode Pubkey Local port Common Stunnel User mode Pubkey Local port Common OpenVPN User mode Pubkey Network Common Tinc User mode Pubkey Network Common WireGuard Kernel PSK Network DKMS IPSec Kernel PSK or Pubkey Network Common TLS User mode Pubkey Local port Common
  7. 7. Application-level TLS
  8. 8. Syntax From https://cipherli.st
  9. 9. Syntax
  10. 10. Syntax
  11. 11. Syntax
  12. 12. Syntax
  13. 13. Syntax
  14. 14. Wonders of X.509
  15. 15. Wonders of X.509
  16. 16. You’ve got choices!
  17. 17. You’ve got choices!
  18. 18. Ahem, syslog, DNS...?
  19. 19. IPSec
  20. 20. History of IPSec
  21. 21. Before
  22. 22. After
  23. 23. Peek inside
  24. 24. IPSec Architecture  ESP (Encapsulation Security Payload)  IPSec bulk encryption workhorse  IP protocol 50 (/etc/protocols)  Kernel space  IKE (Internet Key Exchange)  Authenticate parties  Exchange session keys for ESP and rekey  500/udp  Implemented in a small racoon userspace daemon
  25. 25. TLS-based stack
  26. 26. ESP-based stack
  27. 27. ESP layer details
  28. 28. IPSec configuration in Linux  SPD (Security Policy Database)  “Traffic from A to B must be encrypted”  ”Traffic from A to C may be compressed and encrypted”  “Traffic from A to D goes in plaintext”  SAD (Security Association Database)  “How to encrypt data from A to B”  So you need two SA for bidirectional traffix  Keys  AES-CBC-128 (encryption)  HMAC-SHA256 (authentication & integrify)  SPI (unique SA identifier)  Sequence number, mode, replay protection, expiration date & bytes...
  29. 29. SPD in Linux # ip xfrm policy # setkey -DP
  30. 30. SAD in Linux # ip xfrm state # setkey -D
  31. 31. Implementation  SPD populated by administrator  # setkey -f /etc/ipsec-tools.conf  SAD populated either by  Administrator (manual keying)  Also /etc/ipsec-tools.conf  Racoon daemon (IKE keying)  /etc/racoon/racoon.conf  /etc/racoon/psk.txt  Can also use X.509 certificates
  32. 32. /etc/ipsec-tools.conf Note:  Two entries needed because SA is unidirectional  “transport” mode (the other could be “tunnel”)  “use” opportunistic policy (as opposed to “require”)
  33. 33. /etc/racoon/racoon.conf
  34. 34. More SPD fun Note:  You can disable IPSec for particular protocol, hosts or ports  Four SSH lines because it can be initiated from either host  ...and SA are unidirectional
  35. 35. More SPD fun Note:  You can stack SPD transforms  IPCOMP is IPSec unencrypted compression  We then wrap IPCOMP inside ESP
  36. 36. /etc/racoon/psk.txt Note:  Pre-shared key  Any random string  Has to be the same on both sides, obviously  Long-term, replace e.g. every 6 months  openssl rand -hex 64
  37. 37. IKE operations  You define SPD and hint Racoon on identity of peers  “Kernel, you must encrypt traffic to X”  “Racoon, X is identified by this PSK”  Kernel tries to send packet to X  Hits SPD  First time  Sends request to Racoon to populate SAD  Racoon talks to the other Racoon, exchange keys  Pick up entry for X from SAD
  38. 38. iptables
  39. 39. nftables
  40. 40. Rekeying With Racoon – it just happens In manual mode  Need to periodically delete old, create new SA  Keys defined down to actual hex strings  Short-term, rekey daily
  41. 41. IPCOMP
  42. 42. Troubleshooting
  43. 43. Debugging Dump SAD: # setkey -D Dump SPD: # setkey -DP See traffic: # tcpdump -ni eth0 esp or port 31337
  44. 44. SPD not populated  Causes  Syntax errors in ipsec-tools.conf  IP address mismatch  Setkey not called after reboot  Consequences  Traffic flows unencrypted  Receive unexpected ESP traffic
  45. 45. SAD not populated  Causes  Racoon not running  Racoon fails to establish IKE SA  Keys mismatch in ‘setkey’ mode  Consequences  SPD cannot find matching SA  Traffic flows unencrypted if policy is /use  Traffic dropped if policy is /require
  46. 46. Other issues  Have you checked your firewall?  Assymetric mismatch  Side A requires ESP, side B flushed  Side A refreshed SA, side B didn’t  seq out of sync  MTU in tunnel mode  ip set dev eth0 mtu 1492
  47. 47. IKE failures  Causes  Racoon PSK mismatch  Missing remote section for a host  IP mismatch in remote  Mismatch my_identifier peers_identifier  Debugging  # journalctl -f -u racoon
  48. 48. Ansible
  49. 49. “kravietz.ipsec” role  IPSec configuration is  Repetitive  Sensitive to typos and mismatches  Difficult to write manually  Ansible is a perfect solution for this scenario  Ansible Galaxy role  https://github.com/kravietz/ansible-ipsec
  50. 50. “kravietz.ipsec” role
  51. 51. “kravietz.ipsec” role
  52. 52. Key management IKE mode Setkey mode Single master key ipsec_secret never leaves deploy host
  53. 53. Health & safety  Atomic playbook runs  Prevents partial runs, “unpaired” ESP and IKE  Secret management  Use ansible-vault or other suitable solutions
  54. 54. Q&A pawel.krawczyk@hush.com +44 7879 180015 https://github.com/kravietz/ansible-ipsec

×