[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [leshan-dev] Strange exception?
|
Hi Peter,
sorry, I referred the wrong one. It's the one with the invalid MAC, 4.1.2.1. MAC,
"In general, DTLS implementations SHOULD silently discard records with bad MACs or that are otherwise invalid."
My logs, using a different secret key on the client, shows:
FINE: Discarding Handshake (22) record from peer [/127.0.0.1:35220]: MAC validation failed
So I would suspect the MAC of the FINISHED being wrong.
>From my experience, you would require to build the scandium server from the source to disable the server random
for easier checking the calculations (and disable it in the client as well).
For a more general discussion about the "hold in the light" please use the IETF mailing list for tls!
If there is a conclusion found in the IETF list, I'm pretty sure, it will be adopted and implemented.
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | http://www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Waher
Sent: Donnerstag, 10. August 2017 16:05
To: leshan developer discussions <leshan-dev@xxxxxxxxxxx>
Subject: Re: [leshan-dev] Strange exception?
Hello Kraus
Ok, I will check the links out.
Note however, that the records are all valid, as per §4.1.2.7, RFC 6347, which seem to refer to the record layer and its attributes. Also, how does that argument hold in the light of the other case, where the server responds to a message, containing an invalid identity, which should, by the same reasoning, then also be silenced...? Either silence both cases, or, generate fatal alert messages in both cases. And §4.1.2.7 certainly does not prohibit returning fatal alert messages, rather seems to encourage it, to "avoid attacks where the attacker repeatedly probes the implementation to see how it responds", which is what is possible with today's implementation, since it behaves differently for existing and non-existing identities.
While there might be arguments in favor for silencing both responses, especially in sensitive production environments, note that silencing them, might actually potentially worsen DDoS attacks, since lack of responses trigger retries, even in non-malicious cases with incorrect or obsolete credentials. A fatal alert is better, since it aborts the handshake, and cancels any timers on the client.
Also, since the Leshan.eclipse.org server also acts as some kind of interoperability server, any kind of feedback on errors it finds, would be gratefully received by clients, if reported back to the caller, to facilitate adoption.
Best regards,
Peter Waher
________________________________________
Från: mailto:leshan-dev-bounces@xxxxxxxxxxx <mailto:leshan-dev-bounces@xxxxxxxxxxx> för Kraus Achim (INST/ECS4) <mailto:Achim.Kraus@xxxxxxxxxxxx>
Skickat: den 10 augusti 2017 15:42:13
Till: leshan developer discussions
Ämne: Re: [leshan-dev] Strange exception?
Hi Peter,
the scandium library included in leshan is responsible for that behavior.
Generally, RFC6347, 4.1.2.7. Handling Invalid Records, recommend
"In general, invalid records SHOULD be silently discarded"
Therefore it is currently ignored. If that change is wanted, I would recommend to discuss that first in the IETF Mailing list "mailto:tls@xxxxxxxx";.
But, if your more interested in a successful handshake rather than an AlertMessage,
I would still recommend to use the californium's example DTLS server in " demo-apps\sc-dtls-example-server\" directly to check the handshake.
(the compiled in credentials of that example server are "Client_identity", "secretPSK").
The advantage of using that would be, that setting up logging may be easier then setup the "dual" logging of leshan.
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | http://www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: mailto:leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Waher
Sent: Donnerstag, 10. August 2017 15:16
To: leshan developer discussions <mailto:leshan-dev@xxxxxxxxxxx>
Subject: Re: [leshan-dev] Strange exception?
Hello Kraus
The aim is to use LWM2M over CoAP over DTLS/UDP. The CoAP part (over 5683) already works.
But, the question is: Is Leshan supposed to respond to a finished message with invalid verify data? It responds with an alert message when the identity is incorrect, so it would be logical for it to respond (at least in the same way), if the identity is correct, but the verify data is incorrect. Otherwise you have a method of detected identities registered on the server.
If the server is supposed to respond, and it doesn't, that might be caused by an internal exception? (There's no retransmission of the serverhello either, which is the case if the server did not receive the message.) Such (unexpected?) exceptions are only triggered by the invalid verification data. Would that be of interest to find?
Best regards,
Peter Waher
________________________________________
Från: mailto:leshan-dev-bounces@xxxxxxxxxxx <mailto:leshan-dev-bounces@xxxxxxxxxxx> för Kraus Achim (INST/ECS4) <mailto:Achim.Kraus@xxxxxxxxxxxx>
Skickat: den 10 augusti 2017 15:04
Till: leshan developer discussions
Ämne: Re: [leshan-dev] Strange exception?
Hi Peter,
if I understand you right, your intention is to check DTLS, not LWM2M over coaps?
If so, I guess Simone will remind us pretty soon to move the discussion into the californium mailing list.
Currently I don't run a public accessible DTLS server.
But it's pretty easy to setup the leshan server demo from the github sources or a plain scandium DTLS server.
Though both provide also clients, it may be a possibility to find the difference.
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | http://www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: mailto:leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Waher
Sent: Donnerstag, 10. August 2017 14:52
To: leshan developer discussions <mailto:leshan-dev@xxxxxxxxxxx>
Subject: Re: [leshan-dev] Strange exception?
Hello Krash
Thanks a lot for your quick replies.
There's a high probability of errors on my part in the library as well, when it comes to the cryptographic computations. Many are unit tested (like the AES CCM, and DTLS PRF functions). The DTLS frames and datagrams are also tested, and Wireshark finds no errors also in these. But there might be problems with the verify data in the Finished message of course. I wanted to use the Leshan server to do interoperability testing, and also, to find out what I might have done wrong. I've read and re-read not only the corresponding RFCs and NIST documents, but also the Californium and Scandium source code repositories, to find clues at what my library does different, but reached an end. I wanted to use the debug logs of the Leshan server, but the Leshan server does not respond as expected either. Is it supposed to respond with an alert message, if the verification data is incorrect? I wonder how I might proceed.
I did not build a Leshan server. Instead, I used a Docker image (https://github.com/gebart/leshan-docker). That version worked exactly as the one at leshan.eclipse.org, at the communication level at least.
Is it possible for me to connect to your server? You might see something of interest in the debug log that might explain what happens.
Best regards,
Peter Waher
________________________________________
Från: mailto:leshan-dev-bounces@xxxxxxxxxxx <mailto:leshan-dev-bounces@xxxxxxxxxxx> för Kraus Achim (INST/ECS4) <mailto:Achim.Kraus@xxxxxxxxxxxx>
Skickat: den 10 augusti 2017 14:05:15
Till: leshan developer discussions
Ämne: Re: [leshan-dev] Strange exception?
Hi Peter,
I currently created the snapshot build (commit 09abf9560779dd39f3ed7081d63286680e28cc12),
and tested it locally. But on my side it works :-).
Even if I try to connect the leshan client with the sandbox using
-n "Test client" -i testid -p 01020304 -u leshan.eclipse.org
it works.
So, which client do you use?
Which leshan commit you used to build the server?
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | http://www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: mailto:leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Waher
Sent: Donnerstag, 10. August 2017 12:35
To: mailto:leshan-dev@xxxxxxxxxxx
Subject: [leshan-dev] Strange exception?
Hello
I've experienced a seemingly strange error in the Leshan server. I'm implementing a DTLS library with which I try to establish a session with the Leshan server (leshan.eclipse.org, port 5684) using PSK (TLS_PSK_WITH_AES_128_CCM_8), using an identity (testid) created at http://leshan.eclipse.org/#/security.
If I use the correct identity, the server does not respond at all [1]. However, if I use an invalid identity (testid2), the server responds with an Alert message, telling me the handshake failed [2].
To try to figure out if there's something wrong with the calculations, a college of mine installed a Leshan server (https://github.com/gebart/leshan-docker) hoping to find something in the logs. After creating the same identity/key pair, the server displayed the same behavior as described above. However, looking at the logs [3], a strange error appears:
Aug 09, 2017 10:53:14 PM org.eclipse.californium.scandium.DTLSConnector terminateOngoingHandshake
INFO: Aborting handshake with peer [/90.224.165.60:5684]: Cannot authenticate client, identity [testid] is unknown
The error seems inverted somehow. It's when the correct id is used (testid), that no reply is returned (and the error is logged), while when an invalid id (testid2) is used, a correct alert message is returned to the client (but nothing logged about it in the log).
What is happening here? And how do I proceed? Is the Leshan server supposed to reply? How do I find out if there's something wrong in the calculations, or if something else is wrong in the communication? Or if an unexpected exception in the server caused it to abort the handshake (believing it was caused by an invalid identity)? Is there a way to get access to the debug log on leshan.eclipse.org for example? Or is there anybody with a working server that can help me troubleshoot the communication?
Best regards,
Peter Waher
[1] Using identity testid. No reply from the Leshan server:
[2] Using invalid identity (testid2). Server responds with an alert message:
[3] Log:
2017-08-09 22:50:54,639 INFO LeshanBootstrapServer - Bootstrap server started at coap://0.0.0.0/0.0.0.0:5783, coaps://0.0.0.0/0.0.0.0:5784.
2017-08-09 22:50:55,076 INFO LeshanBootstrapServerDemo - Web server started at http://172.17.0.16:8081/.
Aug 09, 2017 10:50:55 PM org.eclipse.californium.core.CoapServer start
INFO: Starting server
Aug 09, 2017 10:50:55 PM org.eclipse.californium.core.network.CoapEndpoint start
INFO: Starting endpoint at coap://0.0.0.0:5683
Aug 09, 2017 10:50:55 PM org.eclipse.californium.core.network.CoapEndpoint start
INFO: Started endpoint at coap://0.0.0.0:5683
Aug 09, 2017 10:50:55 PM org.eclipse.californium.core.network.CoapEndpoint start
INFO: Starting endpoint at coaps://0.0.0.0:5684
Aug 09, 2017 10:50:55 PM org.eclipse.californium.scandium.DTLSConnector start
INFO: DTLS connector listening on [0.0.0.0/0.0.0.0:5684] with MTU [1,280] using (inbound) datagram buffer size [16,474 bytes]
Aug 09, 2017 10:50:55 PM org.eclipse.californium.core.network.CoapEndpoint start
INFO: Started endpoint at coaps://0.0.0.0:5684
2017-08-09 22:50:55,147 INFO LeshanServer - LWM2M server started at coap://0.0.0.0/0.0.0.0:5683, coaps://0.0.0.0/0.0.0.0:5684.
2017-08-09 22:50:55,301 INFO LeshanServerDemo - Web server started at http://172.17.0.16:8080/.
Aug 09, 2017 10:53:14 PM org.eclipse.californium.scandium.DTLSConnector terminateOngoingHandshake
INFO: Aborting handshake with peer [/90.224.165.60:5684]: Cannot authenticate client, identity [testid] is unknown
2017-08-09 22:56:13,007 ERROR FileSecurityStore - Could not save security infos to file
java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively(Native Method) ~[?:1.8.0_141]
at java.io.File.createNewFile(File.java:1012) ~[?:1.8.0_141]
at org.eclipse.leshan.server.impl.FileSecurityStore.saveToFile(FileSecurityStore.java:119) [leshan-server-demo.jar:?]
at org.eclipse.leshan.server.impl.FileSecurityStore.add(FileSecurityStore.java:68) [leshan-server-demo.jar:?]
at org.eclipse.leshan.server.demo.servlet.SecurityServlet.doPut(SecurityServlet.java:87) [leshan-server-demo.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) [leshan-server-demo.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [leshan-server-demo.jar:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:738) [leshan-server-demo.jar:?]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:551) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [leshan-server-demo.jar:?]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:568) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1111) [leshan-server-demo.jar:?]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:478) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.Server.handle(Server.java:462) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:279) [leshan-server-demo.jar:?]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:232) [leshan-server-demo.jar:?]
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534) [leshan-server-demo.jar:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607) [leshan-server-demo.jar:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536) [leshan-server-demo.jar:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_141]
_______________________________________________
leshan-dev mailing list
mailto:leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
mailto:leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev
