[erlang-questions] Using my own Diffie-Hellman + AES instead of SSL

[Morgan Segalis]

Hi,

Actually, the TTL is just here (on the cassandra column) waiting for the client to disconnect from the GW and connect to the server the gateway specified to it.
If the client is too long connecting to the server, the pair SessionID/Key will be deleted from the Cassandra database and server will refuse the connection, the client will have to restart the connection protocol from the start and go ask for a SessionID/Key to the GW.

Since the client will not be connected more than +/- 1 sec. (Just long enough to SSL handshake with GW, get SessionID/Key pair and the server's ip then disconnect) to the GW, the SSL overhead will not be an issue. 

Thanks,

Morgan.

Le 9 juin 2012 à 10:21, Dmitry Kolesnikov a écrit :

> Hi,
> 
> If "trusted gateway" assign the session key both to client & server then this would be a good compromise. 
> 
> You original concern was a memory overhead for SSL. So you still have SSL in picture and it is handled by GW instead of Servers. 2min TTL is not long enough to dramatically reduce a load. I am not sure if you set-up becomes optimal in terms of costs. Have you estimated GW capacity vs Servers?
> 
> - Dmitry
> 
> On Jun 8, 2012, at 2:06 PM, Morgan Segalis wrote:
> 
>> Hi !
>> 
>> As I explained answering Angela, Here's my idea for the connection protocol I'm thinking about.
>> 
>> 1) The client should connect WITH SSL to a gateway (With Certificate and strong Cipher)
>> 2) Client and Server will negotiate a key together along with a sessionID (not sure we need Diffie-Hellman since it is a secure connection)
>> 3) The sessionID + key will be stored in a cassandra database (With a TimeToLive of 2min or less)
>> 4) The server will tell to which node the client should connect
>> 5) Client disconnects from gateway
>> 6) Client connects to the node specified by the gateway, and gives the SessionID to the node (in clear)
>> 7) The Server node retrieve the Key from the cassandra db
>> 8) If it exist, it sends an accept to the client encrypted, if not, it disconnects the client and we are back to square 1.
>> 9) Both client & server can communicate over AES using the key they now both have.
>> 
>> in part 4, the gateway, a trusted SSL server will give the ip of the node the client should connect (encoded of course). This will make the client able to trust the server.
>> in part 8, the node will accept the client by sending him a specific message, that only a trusted server could have sent. This will make the client able to trust the server.
>> 
>> I'm confident this protocol is secure, and will allow me to have solid encryption while having a good ratio memory/client.
>> But I might be wrong… 
>> 
>> Thanks !
>> 
>> Le 7 juin 2012 à 14:29, dmitry kolesnikov a écrit :
>> 
>>> Hello,
>>> 
>>> I guess you can use crypto:dh_compute_key for DH key exchange procedure.
>>> 
>>> Your application cannot trust server w/o certificates. Therefore
>>> number of attacks are possible. If you are fine with all related
>>> threats then yes this is good option to save memory.
>>> 
>>> On another hand, if you need to use multiple transport e.g. Tcp + udp
>>> then it is good as well.
>>> 
>>> Btw, C ssl API allows to perform SSL:read/write directly to memory. It
>>> would be cool if such feature is available in Erlang. I suppose it
>>> might help to reduce memory footprint for some applications
>>> 
>>> Best Regards,
>>> Dmitry >-|-|-*>
>>> 
>>> 
>>> On 7.6.2012, at 13.35, Morgan Segalis <msegalis@REDACTED> wrote:
>>> 
>>>> Hi everyone,
>>>> 
>>>> As always (for those who remember my old posts), I'm looking to reduce the memory footprint of a secure connection to my server.
>>>> 
>>>> I'm right now looking into doing my own Diffie-Hellman key exchange + AES 128-bit encryption over a TCP connection instead of using Erlang SSL.
>>>> Using SSL with this kinda feels like using a bazooka for smashing a fly.
>>>> 
>>>> The thing is, I do not really need certificates, since the connection url is embedded in a application, and it is using a proprietary protocol.
>>>> 
>>>> Before trying to implement this solution, I would like to hear pros and cons, from Erlang experts on this mailing lists ! (others are welcome too of course ;-) )
>>>> 
>>>> I'm actually looking to implement the same thing as here http://blog.diginux.net/2006/11/15/adding-aes-encryption-to-erlang-chat/
>>>> 
>>>> Thanks for your help.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>