1) I open a bug[1] : 472196, I think there is also a problem in
processAlertRecord() method.
2) It seems good for me. (Even if we seems ok on this I prefer to
precise that this problem is not only for PSK, but for all handshake
problems, this also happened with RPK and X509)
3) I'm sry, but I not really sure to see the solution (I'm not so
familiar with element-connector) , how does it look like at
Endpoint.sendRequest(Request)/MessageObserver level ?
Simon
[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=472196
Le 08/07/2015 17:17, Kai a écrit :
Simon,
thanks for bringing this up. I think that we are facing
multiple issues here.
1) Taking a first look I think you are right regarding the
erroneous implementation of the terminateConnection() method.
It should also try to find an ongoing handshake with the peer
and use the currentWriteState from the session to be
negotiated by the Handshaker. Could you please create an issue
for that in bugzilla?
2) The DTLS spec advises to be very conservative, i.e.
restrictive, regarding the usage for alert messages in
response to erroneous messages received by clients. This is
mainly to prevent amplification of bandwidth usage by an
attacker intentionally sending erroneous records but also to
not expose too much information about the internal workings of
the server. This said, I do believe that we should return an
alert message as proposed by [1] in this case (PSK based
client authentication). Currently, Scandium tries to send a
fatal handshake_failure alert to the peer (which doesn't reach
the client due to the problem described above)
3) From the application layer's point of view (e.g.
Californium or leshan), it seems desirable to be notified
about (fatal) alerts occurring at the DTLS layer in order to
be able to react accordingly, e.g. trying to repeat three
times before logging an error or popping up a warning message
etc. In order to do so, we could introduce means to register
an ErrorHandler with Scandium that would be called back with
alerts occuring at the DTLS connection layer. We could add an
addErrorHandler(ErrorHandler) method to element-connector's
Connector interface for that purpose (similar to how the
application layer registers the RawDataChannel in order to be
called back for application data).
What do you think?
Hi,
I made some tests[1] with Leshan to check the behavoir of
a DTLS handshake failure.
Currently when the server is not able to continue the
handshake (handshake_failure (40), bad_certificate(42),
unsupported_certificate(43), ...) it terminates the session
quietly.
The client will never get a response, and will retry again
an again, this looks like that :
-------(test with bad
psk)-----------
C: Client Hello
S: Hello Verify Request
C: Client Hello
S: Server Hello, Server Hello Done
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
// server does not validate the key and close
the session quietly
// the client try to re-send, and we start a
dialogue of deaf ...
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
S: Client Hello
C: Client Hello
C: Client Hello
S: Server Hello,
Server Hello Done
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
C: Client Key
Exhange, Change Cipher Spec, Encrypted Handshake
message.
S: Client Hello
.... ...
------------------------------------
I don't know if this is the expected behavior.
The TLS 1.2 spec define handshake alert[2] and the
Scandium code seems to use it (AlertDescription.class[3])
I find in the code something which should be a bug in
terminateConnection[4], we send an alert message only if we
have a session in the session store but in case of Handshake
failure we have no session in the store (we add it in the
store only when the handshake is done)
I made a crappy workarround to send the alert message
with the session used by the Handshaker and get this :
-----(test with bad psk + 1
workaround)--
C: Client Hello
S: Hello Verify Request
C: Client Hello
S: Server Hello, Server Hello Done
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
S: Alert (internal error)
// server get the error and send an alert
// the client ignore it and another kind of
dialogue of deaf starts ...
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
S: Client Hello
S: Client Hello
C: Client Hello
S: Alert (Unexpected Message)
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
S: Client Hello
.... ...
------------------------------------
I think we get the same kind of problem at client side when
it receives the alert. This time it's in the
processAlertRecord[5] method.
So, I made the same kind of workaround at client side, the
communication looks better but the client still retry again
and again until timed out :
-----(test with bad
psk + 2 workarounds)--
C: Client Hello
S: Hello Verify Request
C: Client Hello
S: Server Hello, Server Hello Done
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
S: Alert (internal error)
// server get the error and send an alert
// client get it, but retry from beginning
C: Client Hello
S: Hello Verify Request
C: Client Hello
S: Server Hello, Server Hello Done
C: Client Key Exhange, Change Cipher Spec, Encrypted
Handshake message.
S: Alert (internal error)
.... ...
------------------------------------
For a Leshan/Californium user point of view this is a bit
strange. When we send a request through DTLS and the
handshake fails, we get no feedback and the request just
failed with a timeout.
Should we get a message reject instead [6] or something like
that ?
Simon
[1] https://github.com/eclipse/leshan/blob/x509-cert-impl/leshan-integration-tests/src/test/java/org/eclipse/leshan/integration/tests/SecurityTest.java#L66
[2] https://tools.ietf.org/html/rfc5246#appendix-A.3
[3] https://github.com/eclipse/californium.scandium/blob/master/src/main/java/org/eclipse/californium/scandium/dtls/AlertMessage.java#L108
[4] https://github.com/eclipse/californium.scandium/blob/master/src/main/java/org/eclipse/californium/scandium/DTLSConnector.java#L417
[5] https://github.com/eclipse/californium.scandium/blob/master/src/main/java/org/eclipse/californium/scandium/DTLSConnector.java#L482
[6] https://github.com/eclipse/californium/blob/master/californium-core/src/main/java/org/eclipse/californium/core/coap/MessageObserver.java#L69
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|
