CurveZMQ, ZMTP and other Dubious Characters
- 1. CurveZMQ, ZMTP and other Dubious Characters Secure Messaging for the Internet by Pieter Hintjens, CEO, iMatix Berlin Buzzwords 2013, 4 June, 2013
- 2. What's the Problem? ● ZeroMQ (ØMQ) defined a new product category ● Message queuing & routing stacks ● JeroMQ, NullMQ, Nano, netty-zmtp, ezmtp ● All have the same problem: clear-text ● Not safe to use on public infrastructure
- 3. What do People Do? ● Many apps just use clear text ● Clearly not acceptable for sensitive data ● Salt Stack has its own security system ● Already cracked (chicken-salt) ● IPython uses SSH + HMAC digests ● Has several plausible vulnerabilities
- 4. Works in Progress ● TLS encryption above libzmq (Barber) ● TLS transports for libzmq (Young, Naudé) ● DTLS transport for libzmq (Cocagne) ● May deliver, but... ● What about interoperability?
- 5. The Right Solution ● Security at the protocol level (ZMTP) ● Extensible security (like SASL) ● Several example mechanisms ● Easy to plug new ones into libzmq ● Perhaps exposed as e.g. dtls://
- 6. What's SASL? ● IETF's solution for extensible security ● We used this when designing AMQP ● Client and server negotiate a "mechanism" ● Mechanism does the actual security ● IETF as usual makes it... complex ● We can do it somewhat simpler
- 7. The Security Handshake ● Client: HELLO ● Server: WELCOME (mechanism M) ● Client: INITIATE (mechanism M) ● Server: READY ● Client: MESSAGE | Server: MESSAGE
- 8. What is "Secure" in 2013? ● Data cannot be tapped (encrypted) ● or created fraudulently (authentic) ● or altered ● or replayed ● Keys cannot be stolen
- 9. Basic State of the Art ● Mechanisms must be open ended ● Allows evolution of security over time ● Processing HELLO command must be cheap ● Prevents denial-of-CPU attacks ● HELLO must be larger than WELCOME ● Prevents amplification attacks ● Send no metadata until INITIATE/READY ● Prevents leak of knowledge about peer
- 10. Advanced State of the Art ● Perfect forward security ● Data cannot be decrypted even with private keys ● Resists man-in-the-middle manipulation of keys ● Clients cannot be identified ● Client public keys are sent encrypted ● Resists traffic-analysis attacks ● Randomize message sizes & frequencies
- 11. Meet CurveCP (Bernstein) ● "Usable Security for the Internet" ● From author of NaCl (=> libsodium) ● Encryption and authentication over UDP ● Also does recovery from packet loss ● Also does a bunch of other stuff ● http://curvecp.org
- 12. Some CurveCP Internals ● Elliptic curve encryption, very fast ● Creates short-term keys for each connection ● Unique nonces for each command ● Achieves "advanced state of the art" ● Except defeating traffic analysis ● Which we can add ourselves
- 13. Why NaCl is Wonderful ● Perfectly simple API ● Fast and robust ● Preselected key sizes & algorithms ● Packaged as libsodium ● Easy to install, learn, and use
- 14. Why CurveCP won't happen ● Tries to do too much, too soon ● The software is complex to use ● Does not "play nice" with existing standards ● Utterly incompatible with SASL, TCP ● Remixed into more plausible MinimalT
- 15. Apart from that, Very Nice! ● I took CurveCP's security handshake ● Simplified it and cleaned it up ● Made it transport neutral ● Wrote down as a single protocol document ● http://rfc.zeromq.org/spec:26/CURVEZMQ
- 16. Meet CurveZMQ ● An Abstract Security Mechanism ● Specified as a client-server protocol ● Any transport (even avian carrier) ● TCP if we build this into ZMTP ● Or ZeroMQ tcp://, at application level ● http://curvezmq.org
- 17. Meet ZMTP ● The ZeroMQ Message Transport Protocol ● Wire protocol for ZeroMQ over TCP ● Fifth RFC now in drafting stage ● In ZeroMQ, JeroMQ, NetMQ, netty-zmtp, ... ● Version 3.0 is quite a big deal ● http://rfc.zeromq.org/spec:23/ZMTP
- 18. What's New in ZMTP 3.0? ● Extensible security mechanisms ● Extensible connection metadata ● Endpoint resources (for port sharing) ● Better backwards version detection ● Explicit socket type semantics
- 19. ZMTP's security mechanisms ● NULL is just that, empty ● PLAIN does clear-text authentication ● Test clients vs. production systems ● CURVE does CurveZMQ security ● Fully encrypted and authenticated ● <Insert your own here>
- 20. libzmq already runs ZMTP 3.0 ● Git master does NULL and PLAIN ● Full backwards compatibility ● Supports extensible mechanisms ● We're now working on CURVE ● Next: DTLS, ...?
- 21. Meet ZAP ● The ZeroMQ Authentication Protocol ● Extensible authentication services ● Using ZeroMQ request-reply protocol ● PAM, LDAP, Kerberos, passwd, etc. ● libzmq implements ZAP 1.0 ● http://rfc.zeromq.org/spec:27/ZAP
- 22. Get involved ● Read the RFCs on http://rfc.zeromq.org ● Come to Brussels on 21 & 22 June 2013 ● For ZeroMQ Developers' Meetup ● http://zero.mq/bxl ● Talk to us on the zeromq-dev list
- 23. Who are we? ● ZeroMQ community including iMatix ● iMatix makes messaging products ● Distributed systems since 1991 ● Original designers of AMQP (2004-07) ● Backers of ZeroMQ community (2007-) ● Authors of most ZeroMQ RFCs
- 24. Thanks! ● Buy the O'Reilly ZeroMQ book ● Email me: [email protected] ● Twitter: @hintjens ● Blog: hintjens.com