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
_______________________________________________
leshan-dev mailing list
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
