Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
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: ph@imatix.com
● Twitter: @hintjens
● Blog: hintjens.com