Thank a lot for these information Dave. On Sun 18 Nov, 2018, 5:07 AM David Stoddard <[email protected] wrote:
> 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) [email protected] 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 <[email protected]> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
