DTLS is an attempt to use public key cryptography over UDP. It has some performance advantages, but it also has some disadvantages too. Because UDP is connectionless, the sender usually does not know if the receiver has received the packet, and the receiver does not know if the IP address of the sender if legitimate or spoofed. However, DTLS is a handshake protocol, so in order to make DTLS work, the client and the server have to exchange certificates and keys in order to complete the handshake. Because of this, it addresses the problematic issues that plague regular UDP during the initial connection (no verification of receipt and no verification of sender). DTLS requires an exchange between the two systems to complete the handshake. DTLS 1.2 is based on TLS 1.2, so it meets HIPAA and PCI DSS requirements. DTLS works just like TLS, except that there is no initial three-packet handshake (SYN->SYNACK->SYNACK) like in TCP – it just jumps directly into the crypto handshake. The problem is, if the connection breaks after the handshake completes, you may not know it on the sending end unless you build a reply mechanism into your client-server communication (which is what DTLS-SRTP tries to do). TCP does this for you automatically. In addition, you have to handle all of your own packet sequencing issues (which TCP also handles for you automatically). This means that you have to build additional complexity into your communication protocol in order to emulate what TCP gives you. The advantage with DTLS is that you can support a larger number of connections on the same hardware while using less memory per connection – in an application where 100,000 mobile phones may be communicating with your server, that might make a big difference. DTLS is also used for remote terminal access (RDP – it is not a big deal if you lose a couple of pixels on the screen if you are moving a lot of screen data), and some VPNs use DTLS because if a packet gets lost, the encapsulated protocol will detect the lost packet and force a retransmit (ie, tunneling HTTP over a VPN). In my experience, if I don’t have control over the server, then I use TLS 1.2 because all the work for verifying the endpoint is built into the protocol. If I have control over both the client and the server, I have the option to use either UDP or TCP with a shared key between them – this makes things much simpler to build and debug. Best, Dave On Sat, Nov 17, 2018 at 3:31 PM dan (ddp) ddp...@gmail.com <mailto:ddp...@gmail.com> wrote: >How does dtls factor into this? I briefly looked at the wikipedia entry, but >haven’t dug into it yet. On Sat, Nov 17, 2018 at 2:20 PM Dave Stoddard <lamp...@gmail.com <mailto:lamp...@gmail.com> > wrote: Just a note that TLS 1.2 cannot be implemented over UDP. To meet the TLS 1.2 spec, you must use TCP as it requires a connection-oriented protocol. UDP is connectionless - it provides no guarantee that the packet was received at the other end, and there is no guarantee that the packet received by the server originated with the sender IP address found in the UDP packet. TCP requires a three-way handshake to ensure the connection is established, that the two parties to the connection are genuine, and to ensure that packets that are sent are received in the correct sequence. Once the connection is established over TCP, the client requests a secure connection with a list of supported ciphers and hashes. The server picks a cipher and hash and returns the choice to the client. Then the server provides a signed certificate to the client (usually signed by a third party certificate authority), which contains the server's public key. The client verifies the certificate and returns its public key to the server in an encrypted connection using the server's public key to encrypt the response (it is a little more complicated than that, but that is the gist of it in a nutshell). Once the key exchange is completed, data can be exchanged. TLS 1.2 is generally used to support encrypted data exchange when you do not have control over both the client and the server (which is typical for HTTPS or SMTPS). When UDP is used, it is more common to use symmetric keys for data exchange, such as AES 256 with a pre-shared key (PSK). This is the way encryption is implemented for UDP in OSSEC. AES 256 meets the requirements for HIPAA, PDI DSS 3.2, and DFARS (NIST 800-171). Of course, you can use symmetric key cryptography with TCP too. When public key cryptography is used for encryption, as provided through TLS 1.2, the specification of TLS 1.2 for HIPAA, PCI DSS, and other regulatory compliance is done to stop people from using earlier (flawed) versions of PKI, such as SSL 2, SSL 3, TLS 1.0, and TLS 1.1. While it is generally recommended not to "roll your own" cryptography, the open source OpenSSL library provides a complete set of wrapper functions through the EVP interface that make it easy to implement encryption for almost any cipher using C/C++ (Google for "openssl evp functions" for more info). Most mainstream programming languages provide libraries to support encryption protocols, including Python, Perl, Go, and many others. Hope this helps. Best, Dave Stoddard Network Alarm Corporation https://networkalarmcorp.com https://redgravity.net dgs at networkalarmcorp dot com
-- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
