5 ms·

Minor nit that I almost hesitate to pick but I've been doing 100-series network training lately so this is something that I'd tell my students: > UDP packets a

Minor nit that I almost hesitate to pick but I've been doing 100-series network training lately so this is something that I'd tell my students: > UDP packets are not encrypted, so any data sent over these packets could be sniffed and read by an attacker, or even modified in transmit. It would be a massive step back for web security to create a new way for browsers to send unencrypted packets. TCP packets are not encrypted, either. That data is transmitted via UDP or TCP doesn't make it encrypted; encryption is handled elsewhere. Now if you insist that the contents of the transmitted UDP packets are encrypted--as the author does with the documented proposal--then that's one thing. But the data transport mechanism (UDP vs. TCP) doesn't inherently mean encryption. (Fun fact I learned while writing words about TLS: Use of TLS does not automatically imply confidentiality--that is, encryption--of the data being transported. TLS supports a NULL cipher[0] that ensures integrity and authenticity but the payload is "in the clear.") 0 - https://tools.ietf.org/html/rfc4785 https://tools.ietf.org/html/rfc4785

thezilch 10y ago
You're not wrong, but I think the point was, in a browser, you can get your TCP _connection_ "automatically" encrypted by connecting to HTTPS endpoints. It's not so easy -- "built in" -- with a connectionless protocol.
- techsupporter 10y ago
  That's entirely true and it's one reason why I hesitated before nitpicking. That said, I think that the distinction should be properly made when someone is discussing a new way to sling data over a network from the application layer. If the author had written what you'd written, I'd have let my reply go. (Even so, it's not that the "TCP session" is encrypted; it's that the transport-layer security mechanism encrypts the payload of the TCP session. The metadata for the session--the respective IP addresses, sequence/acknowledgement numbers, and so on--is still in the clear. I realize that, at this point, I'm being quite pedantic but I'm a networking person at heart and I want software developers to better understand the infrastructure that's being used.)
  - disiplus 10y ago
    i think its fair what you said. webrtc offers "automatically" encrypted UDP if we are comparing like that.
    - thezilch 10y ago
      But we already knew that. It's in the article, so again there is a story here that you're missing. We want a client/server protocol that is encrypted and simple -- not requiring ICE/STUN/TURN (OMG).
      - stcredzero 10y ago
        If you already have Websockets, then Simple-Peer makes it very easy to deal with WebRTC negotiation. As I've mentioned elsewhere, I've created a 4 process WebRTC UDP proxy with that running under nodejs. My use case is precisely client-server.
- bdonlan 10y ago
  There is DTLS if you really want turnkey encryption for UDP, and it's implemented by openssl so it's straightforward enough to find an implementation. Not the most widely deployed protocol out there, to be sure, but if browsers wanted to make that the condition of use it would soon become widely implemented.
  - thezilch 10y ago
    "openssl [...] straightforward" I don't think so. It's in the article; DTLS is too complex. The author wants something simple. Most implementations (eg. WebRTC) involve pulling in truck loads of C libs; it's insane. And then you want to support other clients? Good luck.
  - warbiscuit 10y ago
    Not quite turnkey, but openvpn is essentially tls over udp with an ip tunnel on top
sargun 10y ago
This is also true of IPSec AH and ESP. You can use it purely for labeling (turn off both)
- huhtenberg 10y ago
  IPsec, not IPSec It's been 10 years since I worked on a VPN stack, but naming pedantry dies hard.
johnflan 10y ago
Actually the encryption question is interesting, you couldn't use modes like CBC in out of order. What technique would be used for out of order decryption?
- brians 10y ago
  Pick your mode, separate IV per record, separate record per packet.
rusk 10y ago
I have implemented TLS on UDP. Basically to implement an EAP-TTLS authentication service which sets up a TLS tunnel over EAP over RADIUS over UDP. I can attest that is "doable" but is horrendously complicated. Not just to implement but to monitor and debug. It "works" in the case of EAP because you're never sending more than a few datagrams at a time, and if one gets lost it's not a huge tragedy to have to start the whole process again ... but, I can't imagine this being feasible for more continuous data-transfers such as streaming data "oops you lost a packet - sorry you'll have to re-establish your TLS session again" I did notice the DTLS thing lying around when I was browsing the OpenSSL source but as another commenter says it's not that popular and presumably suffers many of the same complications.
- hamandcheese 10y ago
  Is there a reason you couldn't use TCP/TLS to establish a shared secret, and then just encrypt all your packets with that?
  - rusk 10y ago
    Gosh .. I eh .. I guess I was just given this RFC to implement [0] I'm not sure of the reasoning specifically for doing it this way. But kind of related to your point, TTLS does in fact use the "cryptographic material" derived as part of session establishment to derive a shared secret for hashing in CHAP, MS-CHAP and MS-CHAP-v2! [1] The nifty thing about that is it "binds" the ensuing authentication process to the actual TLS session. With MS-CHAP-v2 it also provides for mutual authentication without either party ever having to exchange sensitive info (neither client nor server ever has to know the password). This was actually a real pain to do with Open SSL as that information wasn't readily available with the standard API. I had to implement some horrific cludge to get the necessary info nested within 3 layers of structs. [0] https://tools.ietf.org/html/rfc5281 https://tools.ietf.org/html/rfc5281 [1] https://tools.ietf.org/html/rfc5281#section-8 https://tools.ietf.org/html/rfc5281#section-8
- platform 10y ago
  DTLS is a foundation of CoAP protocol (request/response) for the IoT world [1] I personally think, it will see wider usage in upcoming decade.. but it is just a guess. [1] https://projects.eclipse.org/projects/iot.tinydtls https://projects.eclipse.org/projects/iot.tinydtls
k_lander 10y ago
> UDP packets are not encrypted how does QUIC do encryption?
- pthatcherg 10y ago
  QUIC Crypto design doc: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...

thezilch 10y ago

You're not wrong, but I think the point was, in a browser, you can get your TCP _connection_ "automatically" encrypted by connecting to HTTPS endpoints. It's not so easy -- "built in" -- with a connectionless protocol.

techsupporter 10y ago
That's entirely true and it's one reason why I hesitated before nitpicking. That said, I think that the distinction should be properly made when someone is discussing a new way to sling data over a network from the application layer. If the author had written what you'd written, I'd have let my reply go. (Even so, it's not that the "TCP session" is encrypted; it's that the transport-layer security mechanism encrypts the payload of the TCP session. The metadata for the session--the respective IP addresses, sequence/acknowledgement numbers, and so on--is still in the clear. I realize that, at this point, I'm being quite pedantic but I'm a networking person at heart and I want software developers to better understand the infrastructure that's being used.)
- disiplus 10y ago
  i think its fair what you said. webrtc offers "automatically" encrypted UDP if we are comparing like that.
  - thezilch 10y ago
    But we already knew that. It's in the article, so again there is a story here that you're missing. We want a client/server protocol that is encrypted and simple -- not requiring ICE/STUN/TURN (OMG).
    - stcredzero 10y ago
      If you already have Websockets, then Simple-Peer makes it very easy to deal with WebRTC negotiation. As I've mentioned elsewhere, I've created a 4 process WebRTC UDP proxy with that running under nodejs. My use case is precisely client-server.
bdonlan 10y ago
There is DTLS if you really want turnkey encryption for UDP, and it's implemented by openssl so it's straightforward enough to find an implementation. Not the most widely deployed protocol out there, to be sure, but if browsers wanted to make that the condition of use it would soon become widely implemented.
- thezilch 10y ago
  "openssl [...] straightforward" I don't think so. It's in the article; DTLS is too complex. The author wants something simple. Most implementations (eg. WebRTC) involve pulling in truck loads of C libs; it's insane. And then you want to support other clients? Good luck.
- warbiscuit 10y ago
  Not quite turnkey, but openvpn is essentially tls over udp with an ip tunnel on top

sargun 10y ago

This is also true of IPSec AH and ESP. You can use it purely for labeling (turn off both)

huhtenberg 10y ago
IPsec, not IPSec It's been 10 years since I worked on a VPN stack, but naming pedantry dies hard.

johnflan 10y ago

Actually the encryption question is interesting, you couldn't use modes like CBC in out of order. What technique would be used for out of order decryption?

brians 10y ago
Pick your mode, separate IV per record, separate record per packet.

rusk 10y ago

I have implemented TLS on UDP. Basically to implement an EAP-TTLS authentication service which sets up a TLS tunnel over EAP over RADIUS over UDP. I can attest that is "doable" but is horrendously complicated. Not just to implement but to monitor and debug. It "works" in the case of EAP because you're never sending more than a few datagrams at a time, and if one gets lost it's not a huge tragedy to have to start the whole process again ... but, I can't imagine this being feasible for more continuous data-transfers such as streaming data "oops you lost a packet - sorry you'll have to re-establish your TLS session again" I did notice the DTLS thing lying around when I was browsing the OpenSSL source but as another commenter says it's not that popular and presumably suffers many of the same complications.

hamandcheese 10y ago
Is there a reason you couldn't use TCP/TLS to establish a shared secret, and then just encrypt all your packets with that?
- rusk 10y ago
  Gosh .. I eh .. I guess I was just given this RFC to implement [0] I'm not sure of the reasoning specifically for doing it this way. But kind of related to your point, TTLS does in fact use the "cryptographic material" derived as part of session establishment to derive a shared secret for hashing in CHAP, MS-CHAP and MS-CHAP-v2! [1] The nifty thing about that is it "binds" the ensuing authentication process to the actual TLS session. With MS-CHAP-v2 it also provides for mutual authentication without either party ever having to exchange sensitive info (neither client nor server ever has to know the password). This was actually a real pain to do with Open SSL as that information wasn't readily available with the standard API. I had to implement some horrific cludge to get the necessary info nested within 3 layers of structs. [0] https://tools.ietf.org/html/rfc5281 https://tools.ietf.org/html/rfc5281 [1] https://tools.ietf.org/html/rfc5281#section-8 https://tools.ietf.org/html/rfc5281#section-8
platform 10y ago
DTLS is a foundation of CoAP protocol (request/response) for the IoT world [1] I personally think, it will see wider usage in upcoming decade.. but it is just a guess. [1] https://projects.eclipse.org/projects/iot.tinydtls https://projects.eclipse.org/projects/iot.tinydtls

k_lander 10y ago

> UDP packets are not encrypted how does QUIC do encryption?

pthatcherg 10y ago
QUIC Crypto design doc: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...