gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TLS handshake problems


From: Sebastien Decugis
Subject: Re: TLS handshake problems
Date: Fri, 28 Nov 2008 10:23:55 +0900
User-agent: Thunderbird 2.0.0.18 (Windows/20081105)

Hello,

This is not an answer to your TLS problem, but I'd like to highlight
that in Diameter if the TLS handshake fails you don't have to send a
DPR. Here is an extract from draft-ietf-dime-rfc3588bis-14 section 5.6:

"   If the TLS handshake is successful, all further messages
   will be sent via TLS.  If the handshake fails, both ends move to the
   closed state."


I believe this provides you a workaround for your problem, since if the
connection is simply closed, your client will exit the handshake routine.

Best regards,
Sebastien.


Metzler, Richard a écrit :
>
> Hello,
>
> currently I am testing a TLS connection using Gnu TLS 2.2.5.on server
> and client side. For the TCP communication Diameter is used.
>
> There are situations that on both sides the TLS handshake fails, e.g.
> due to a wrong client certificate (Gnu TLS error code
> NO_CERTIFICATE_FOUND). But in this special case the server finishes
> the handshake with error and the client is still waiting in the handshake.
>
> Now the server announces closing the connection to the client by
> sending the Diameter disconnect message (DPR). This message is
> received by the client Gnu TLS when expecting a TLS message,
> preventing a correct shut down of the connection.
>
> To avoid this problem I added a call to gnutls_alert_send_appropriate
> in case the server finishes the handshake with errors. This helps to
> finish the handshake on the client side in this case, but there are
> situations when the handshake is finished on both sides with an error.
> Then the additional alert message would be interpreted on the client
> side as Diameter message which also is not correct.
>
> My question is, is there a way for the server to decide whether the
> alert has to be sent or not, i.e. to detect the state of the client –
> maybe by evaluating the result code of the handshake?
>
> Regards,
>
> Richard
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> LHS Telekommunikation GmbH & Co. KG,
>
> Address: Herriotstrasse 1, D-60528 Frankfurt, Germany,
>
> Phone +49 (0)69 2383 3000, Fax +49 (0)69 2383 5000
>
> Commercial Register: Amtsgericht Frankfurt/Main - Registration Number
> HRA 42727
>
> Personally Liable Partner: LHS Management GmbH - Registration Number
> HRB 75504
>
> Amtsgericht Frankfurt/Main
>
> Managing Directors: Wolfgang Kroh, Axel Barta, Dr. Jens Troetscher
>
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gnutls-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>   

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]