The Remus post basically cautions against creating your own crypto protocols (because you are likely to make some fatal error) and use the existing SSL solution instead.
You can write a secure network protocol using only Diffie-Hellman as an asymmetric cryptogram along with some symmetric crypto. My favorite secure network protocol works that way. A program using DH is no weaker than SSL in itself, but a program in which, most likely, not a crypto option was developed, a developed protocol.
But if you develop your own protocol, you will need to learn a little cryptography to get it right. You probably need a peer review for your design and code if you made a mistake somewhere. But getting this review is not easy if your product is not well-known or you pay them.
SSL confirmation does two basic things:
It uses a certificate to verify that the server is authorized to represent the domain with which you want to communicate.
In the most common case, the Certification Authority notes that the owner of a certain key pair is the legal owner of a certain domain (this takes the form of a certificate). This part is as safe as the weakest CA.
If you only need to exchange data with only one server, you can hard-edit the server fingerprint, cutting out all of the CA and PKI. This approach is similar to the way you usually handle SSH fingerprints.
It generates a session key.
Strong SSL packets use a certificate for server authentication and DH to generate a session key. Weaker apartments use a certificate for both.
Naive DH-based protocols are likely to forget to authenticate the server, allowing an active attacker to connect to MitM. You need to somehow authenticate the server, even if it is simply by hard-coding the serverβs public key on your client.
source share