Hi
Simon,
First
results:
Openssl
1.1.1 uses 1.0, mbedtls uses 1.2 for that
HelloVerifyRequest.
Both
clients works with 1.2 or 1.0
From
your previous mail:
The server MUST use the same
version number in the HelloVerifyRequest that it would use when
sending a ServerHello.
That’s
interesting … and doesn’t fit. So I will write to
the ietf-tls-list.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch IoT Hub - Product Area IoT Platform
(IOC/PAP-HU)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332
Waiblingen |
GERMANY | www.bosch.io
Sitz: Berlin, Registergericht: Amtsgericht
Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke;
Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar
Mitrovic, Yvonne Reckling
As you are here Achim, I will not open a
dedicated issue in californium.
Let discuss about it here.
My first point : I'm not sure this is a good idea to
change default behavior in a minor version release. In
this particular case we could maybe considered this as
a bug fix (But I'm not sure of this as this is just a
SHOULD and not a MUST).
My second point : About the RFC, it says :
1. TLS 1.2 server implementations SHOULD use DTLS
2. version 1.0 regardless of the version of TLS that is expected to be
3. negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to
4. indicate packet formatting (which is the same in both DTLS 1.2 and
5. 1.0) and not as part of version negotiation. In particular, DTLS 1.2
6. clients MUST NOT assume that because the server uses version 1.0 in
7. the HelloVerifyRequest that the server is not DTLS 1.2 or that it
8. will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
9. The server MUST use the same
10. version number in the HelloVerifyRequest that it would use when
11. sending a ServerHello.
So
I'm not sure to understand this correctly ? Does it
means that a DTLS 1.2 server SHOULD use 1.2 version in
hello_verfiy_request ? Using 1.0 version is only for
server which support 1.0 to 1.2 ?
(I suppose you have another understanding else you
didn't implement this ? or maybe you just missed the
second sentence ?)
Mark,
no matter how this discussion will end, your
device seems to not respect this part of the RFC :
In particular, DTLS 1.2
clients MUST NOT assume that because the server uses version 1.0 in
the HelloVerifyRequest that the server is not DTLS 1.2 or that it
will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
So you should report this.
Simon
Le
23/11/2020 à 16:48, Kraus Achim (IOC/PAP-HU) a
écrit :
Hi
together,
there
is a
DtlsConfiguration.Builder.setProtocolVersionForHelloVerifyRequests.
That
may help out.
It’s
always not too easy, to fix something according
a RFC, if some implementations are used to
behave different ;-).
Mit
freundlichen Grüßen / Best regards
Achim Kraus
Bosch IoT Hub - Product Area IoT Platform
(IOC/PAP-HU)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332
Waiblingen |
GERMANY | www.bosch.io
Sitz: Berlin, Registergericht: Amtsgericht
Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten
Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr.
Aleksandar Mitrovic, Yvonne Reckling
I bet this could be
because of :
https://github.com/eclipse/californium/pull/1397
See :
https://tools.ietf.org/html/rfc6347#section-4.2.1
The default VERSION value changes which change
default behavior, but this changes follow a RFC
recommendation so I'm not sure if this will(or
even should) be changed back ? (My guess is
probably not)
This is possible to change it using the API, see :
https://github.com/eclipse/californium/pull/1397/files#diff-3c57eeacb63a45e50c11737e09d3e166367773a093f2cb216e3ece81f2477597R1606
(but this will probably not changed on the
sandbox)
Le
23/11/2020 à 16:17, Simon Bernard a écrit :
We succeed to get a capture. I joined it.
Your device sounds to not answer to
HELLO_VERIFY_REQUEST from the server.
I guess there is some changes about this at
Californium side. I will open a ticket to
discuss about this. Please do not hesitate to
join the discussion.
Le
23/11/2020 à 15:36, Simon Bernard a écrit :
Hi,
You can eventually run leshan-server-demo
locally and so run wireshark at server side.
Or Eventually, I can try to do a capture at
server side. (as there is not so much traffic)
I'm currently running a tcpdump on the
sandbox. If you make your device communicate
now I can see the exchange.
(This will maybe be complicated to synchronize
ourself, I will let the tcpdump capturing for
the next hour but I will stop it before the
end of the day)
Simon
Le
23/11/2020 à 15:00, Mark Lugovskoy a écrit :
Hi,
I
tried to connect using this sequence of
commands from GSM modem:
AT#LWM2MINJKEYS=0,1,"mark123456","mark123456","0987654321"
AT#LWM2MSTS=0,999,"coaps://leshan.eclipseprojects.io:5784",1
at#reboot
AT#LWM2MENA=1
With
this sequence, I managed to connect
until Thursday after noon. In the
evening I already couldn’t connect.
I
pretty much use my GSM modem as black
box, so I can’t provide much more
details. I also don’t have Wireshark.
I’ll
try to find more information that you
asked.
Thank
you,
Mark
From:
Thomas LE ROUX [mailto:thomas.leroux@xxxxxxxx]
Sent: Monday, November 23, 2020
3:33 PM
To: leshan developer discussions
<leshan-dev@xxxxxxxxxxx>
Cc: Mark Lugovskoy <mark.lugovskoy-ext@xxxxxxx>
Subject: Re: [leshan-dev] A
question regarding Leshan demo web site
There
must be something wrong with either
your computer's networking options,
the sequence of command you used,
registration to the server (wrong key,
or a device with the same identity is
registered with a wrong key. You can
check this out at
https://leshan.eclipseprojects.io/#/security) or something else.
Hi,
Is
there some problem with this
server?
It should not. But you maybe found a
bug ?
Thursday I integrated in master
(and so applied on Leshan sandbox)
some commits about integration of
the new Californium version, there
is maybe a regression with this.
(Californium itself or my
modifications)
This could help if you provide
more context. (which client used ?
DTLS or not ?, if DTLS, rpk psk or
x509 ? providing wireshark capture
or log could help too)
If you prefer you can use github
issue ? (Mailing list is fine too)
Simon
Le
23/11/2020 à 13:17, Mark Lugovskoy
a écrit :
Hi,
Last
week I connected with my device
successfully to the demo LESHAN
server:
https://leshan.eclipseprojects.io/#/clients.
But
since Thursday I can’t connect
to it, with the same sequence of
commands that I used before.
Is
there some problem with this
server?
Thank
you,
Mark
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/leshan-dev
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/leshan-dev
