Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Matt Caswell]

On 19/01/18 16:32, Michael Richardson wrote:
> Matt Caswell  wrote:
> > Please raise a separate PR for this work. It *must* be portable though
> > and work across all our platforms (e.g. including VisualC etc). My
> > suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
> > ctrls should return an error on platforms that we don't know we can
> > support, i.e. attempt to detect (at compile time) whether we are on a
> > platform that we know has the required system calls - if we are then use
> > them, otherwise we do things the old way.
> 
> > Note that stuff like this is problematic:
> 
> > char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
> > in_pktinfo))];
> 
> > The "attribute" is compiler specific and not something we can rely on to
> > be available. Additionally "CMSG_SPACE" is probably not portable, and in
> > any case may not evaluate to a compile time constant (according to the
> > man page), so this is not C90 (which is a requirement for OpenSSL
> > submissions).
> 
> Understood.
> I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.
> 
> What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
> A bunch of #ifdef on OS definitions?

If its non portable and we're not already using it then that's the
probably the best we can do. We should try and provide some sensible
fallback wherever possible. Or if not possible it shouldn't break
anything that already works.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell  wrote:
> Please raise a separate PR for this work. It *must* be portable though
> and work across all our platforms (e.g. including VisualC etc). My
> suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
> ctrls should return an error on platforms that we don't know we can
> support, i.e. attempt to detect (at compile time) whether we are on a
> platform that we know has the required system calls - if we are then use
> them, otherwise we do things the old way.

> Note that stuff like this is problematic:

> char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
> in_pktinfo))];

> The "attribute" is compiler specific and not something we can rely on to
> be available. Additionally "CMSG_SPACE" is probably not portable, and in
> any case may not evaluate to a compile time constant (according to the
> man page), so this is not C90 (which is a requirement for OpenSSL
> submissions).

Understood.
I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.

What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
A bunch of #ifdef on OS definitions?

> Once this PR is in (assuming it gets accepted), then you can look at
> what remains of your original PR and see if it makes sense to raise new
> PRs to bring the rest of it in.

Roger. Wilco.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Matt Caswell]

On 17/01/18 16:34, Michael Richardson wrote:
> 
> > It seems like a fairly simple solution could solve this. Currently we
> > have BIO_dgram_get_peer() which returns the peer's address for the last
> > message read from a BIO. You could imagine a new call being introduced
> > to get our own address. You could then call that immediately after a
> > successful DTLSv1_listen() call. Obviously we'd have to change the
> > dgram BIO to use recvmsg for this to work.
> 
> That's here:
>
> https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
>
> https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
> and:   
> https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323

Please raise a separate PR for this work. It *must* be portable though
and work across all our platforms (e.g. including VisualC etc). My
suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
ctrls should return an error on platforms that we don't know we can
support, i.e. attempt to detect (at compile time) whether we are on a
platform that we know has the required system calls - if we are then use
them, otherwise we do things the old way.

Note that stuff like this is problematic:

char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
in_pktinfo))];

The "attribute" is compiler specific and not something we can rely on to
be available. Additionally "CMSG_SPACE" is probably not portable, and in
any case may not evaluate to a compile time constant (according to the
man page), so this is not C90 (which is a requirement for OpenSSL
submissions).

I suggest you Configure with the "--strict-warnings" option which will
probably complain about some of this stuff.

Please also make sure we have suitable documentation and ideally tests too.

Once this PR is in (assuming it gets accepted), then you can look at
what remains of your original PR and see if it makes sense to raise new
PRs to bring the rest of it in.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell  wrote:
>> Matt Caswell  wrote:
>> >> Matt Caswell  wrote: >> a) when the existing FD is
>> >> connect(2) any future traffic to the bound >> port will get rejected
>> >> with no port.  So the application really has to >> open a new socket
>> >> first.  The application can do this two ways: it can >> open a new
>> >> socket on which to receive new connections, or it can open >> a new
>> >> socket on which to communicate with the new client.  The second >>
>> >> method is better for reason (b) below.  Either way, it socket to >>
>> >> communicate with the client needs to be bind(2) to the address that >>
>> >> the client used to communicate with the server, and DTLSv1_listen() >>
>> >> didn't collect or return that information.
>> >>
>> >> > The second way is what is intended.
>> >>
>> >> Unfortunately, there remains a race condition because we have to call
>> >> bind() before connect() on the new socket.  Under load, if a packet is
>> >> received between the bind() and the connect(), it might go onto the
>> >> wrong socket queue. So some packets that could have been processed
>> >> will get dropped and have to be retransmitted by the client.
>>
>> > This seems like a non-issue to me. At this point in the handshake the
>> > client will have sent its ClientHello and won't progress until it gets
>> > the server's flight back (ServerHello etc), i.e. in the vast majority
>> > of cases it won't be sending anything.
>>
>> *That* client will be waiting, but other clients may be sending new 
ClientHello
>> messages (with or without cookies).

> So how does your refactor solve this issue? AFAICT this also just does a
> bind then connect:

My refactor does not solve it. I'm noting that this is still an issue.

It's not solvable unless the kernel can do both operations at the same time,
for which there isn't a standard call (nor a non-standard one).
If we could punt segments between BIOs easily, then we could deal with the
problem, but I don't think it's worth solving.


> if(bind(rfd,BIO_ADDR_sockaddr(ouraddr),BIO_ADDR_sockaddr_size(ouraddr))
> != 0){
> +  goto end;
> +}
> +
> if(connect(rfd,BIO_ADDR_sockaddr(client),BIO_ADDR_sockaddr_size(client))
> != 0) {
> +  goto end;
> +}

> Doesn't this suffer from the same problem? i.e. packets could arrive
> from other clients between the bind and connect.

Yes.

This is in contrast this situation to the original problem with connect()'ing
the socket which is given to DTLSv1_listen(). That socket has lots of time
between the two points in which to accumulate new connection requests.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell  wrote:
>> Matt Caswell  wrote: >> a) when the existing FD is
>> connect(2) any future traffic to the bound >> port will get rejected
>> with no port.  So the application really has to >> open a new socket
>> first.  The application can do this two ways: it can >> open a new
>> socket on which to receive new connections, or it can open >> a new
>> socket on which to communicate with the new client.  The second >>
>> method is better for reason (b) below.  Either way, it socket to >>
>> communicate with the client needs to be bind(2) to the address that >>
>> the client used to communicate with the server, and DTLSv1_listen() >>
>> didn't collect or return that information.
>>
>> > The second way is what is intended.
>>
>> Unfortunately, there remains a race condition because we have to call
>> bind() before connect() on the new socket.  Under load, if a packet is
>> received between the bind() and the connect(), it might go onto the
>> wrong socket queue. So some packets that could have been processed
>> will get dropped and have to be retransmitted by the client.

> This seems like a non-issue to me. At this point in the handshake the
> client will have sent its ClientHello and won't progress until it gets
> the server's flight back (ServerHello etc), i.e. in the vast majority
> of cases it won't be sending anything.

*That* client will be waiting, but other clients may be sending new ClientHello
messages (with or without cookies).

>> The address of the remote client is returned ("getpeername()") by
>> DTLSv1_listen().  That's all that recvfrom() gives you.
>>
>> recvfrom() was a reasonable API for SunOS 3.x machines with a single
>> 10Mb/s interface with a single IPv4 address.  I loved all that at the
>> time...  But it doesn't work that well when we might have a dozen
>> different kind of IPv6 addresses on each virtual interface.
>>
>> The address that I'm talking about needing is the one the remote
>> client used to reach us.  That's the destination IP of the incoming
>> packet ("getsockname()" in TCP speak).

> Ahhhits the *server's* address you are after. This requirement
> seems more reasonable. I think the API is designed to expect you to
> only bind to a single IP. I'd be interested in Richard Levitte's
> opinion on this.

okay.
binding to a single IP is not scalable in many applications.

> It seems like a fairly simple solution could solve this. Currently we
> have BIO_dgram_get_peer() which returns the peer's address for the last
> message read from a BIO. You could imagine a new call being introduced
> to get our own address. You could then call that immediately after a
> successful DTLSv1_listen() call. Obviously we'd have to change the
> dgram BIO to use recvmsg for this to work.

That's here:
   
https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
   
https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
and:   
https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323


--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Matt Caswell]

On 16/01/18 19:44, Michael Richardson wrote:
> 
> Matt Caswell  wrote:
> >> a) when the existing FD is connect(2) any future traffic to the bound
> >> port will get rejected with no port.  So the application really has to
> >> open a new socket first.  The application can do this two ways: it can
> >> open a new socket on which to receive new connections, or it can open
> >> a new socket on which to communicate with the new client.  The second
> >> method is better for reason (b) below.  Either way, it socket to
> >> communicate with the client needs to be bind(2) to the address that
> >> the client used to communicate with the server, and DTLSv1_listen()
> >> didn't collect or return that information.
> 
> > The second way is what is intended.
> 
> Unfortunately, there remains a race condition because we have to call bind()
> before connect() on the new socket.  Under load, if a packet is received
> between the bind() and the connect(), it might go onto the wrong socket
> queue. So some packets that could have been processed will get dropped and
> have to be retransmitted by the client.

This seems like a non-issue to me. At this point in the handshake the
client will have sent its ClientHello and won't progress until it gets
the server's flight back (ServerHello etc), i.e. in the vast majority of
cases it won't be sending anything.

It is possible that the client may retransmit the ClientHello if the
server hasn't responded within a timely manner. Retransmit times are
usually quite a while (relatively speaking) after the original
transmission, so the chances of this happening immediately after we've
processed the original ClientHello and before we've called connect()
seem quite small - although possible. If a retransmitted ClientHello
arrives *after* the connect() it will be dropped anyway by OpenSSL so we
really don't care about these messages going missing.

Another possibility is that the client transmits an alert of some form.
This also seems quite unlikely (i.e. send a ClientHello and then
immediately send an alert before the server has had a chance to respond)
- but again, its possible. It would be bad luck indeed for this unlikely
scenario to happen and then for the alert to not make it onto the right
fd due to the race: but if it did its not a big deal. This connection is
doomed in any case (an alert was sent) and we have to be prepared to
deal with packets getting dropped anyway (this is DTLS!). It is very
common for clients to just abort without sending an alert anyway - so
this will just appear like that.

> 
> It could be solved if there was a way to punt packets received on the wrong
> socket to the correct BIO on the input side.  I looked into this, but decided
> it was too difficult...
> 
> That would also let one operate a multitude of DTLS connections using single
> socket which might be a boon to some users.  Mis-designed it would scale
> badly on multi-threaded machines and involve lots of ugly locks.
> I don't want to consider the impacts if one had to pass packets between 
> processes...
> I don't advocate a solution like this (I'll live with the dropped packets),
> but I think it's worth making people aware that they might see mis-directed
> packets get dropped.
> 
> > Maybe I misunderstand your point -
> > but the client address *is* returned? Admittedly its wrapped in a
> > BIO_ADDR, but its easy to get the underlying "raw" address using
> > BIO_ADDR_rawaddress():
> 
> > Why isn't recvfrom() suitable (which is what the code currently uses to
> > get the address)?
> 
> The address of the remote client is returned ("getpeername()") by 
> DTLSv1_listen().
> That's all that recvfrom() gives you.
> 
> recvfrom() was a reasonable API for SunOS 3.x machines with a single 10Mb/s
> interface with a single IPv4 address.  I loved all that at the time...
> But it doesn't work that well when we might have a dozen different kind of
> IPv6 addresses on each virtual interface.
> 
> The address that I'm talking about needing is the one the remote client used
> to reach us.  That's the destination IP of the incoming packet 
> ("getsockname()" in TCP speak).

Ahhhits the *server's* address you are after. This requirement seems
more reasonable. I think the API is designed to expect you to only bind
to a single IP. I'd be interested in Richard Levitte's opinion on this.

It seems like a fairly simple solution could solve this. Currently we
have BIO_dgram_get_peer() which returns the peer's address for the last
message read from a BIO. You could imagine a new call being introduced
to get our own address. You could then call that immediately after a
successful DTLSv1_listen() call. Obviously we'd have to change the dgram
BIO to use recvmsg for this to work.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

Matt Caswell  wrote:
>> a) when the existing FD is connect(2) any future traffic to the bound
>> port will get rejected with no port.  So the application really has to
>> open a new socket first.  The application can do this two ways: it can
>> open a new socket on which to receive new connections, or it can open
>> a new socket on which to communicate with the new client.  The second
>> method is better for reason (b) below.  Either way, it socket to
>> communicate with the client needs to be bind(2) to the address that
>> the client used to communicate with the server, and DTLSv1_listen()
>> didn't collect or return that information.

> The second way is what is intended.

Unfortunately, there remains a race condition because we have to call bind()
before connect() on the new socket.  Under load, if a packet is received
between the bind() and the connect(), it might go onto the wrong socket
queue. So some packets that could have been processed will get dropped and
have to be retransmitted by the client.

It could be solved if there was a way to punt packets received on the wrong
socket to the correct BIO on the input side.  I looked into this, but decided
it was too difficult...

That would also let one operate a multitude of DTLS connections using single
socket which might be a boon to some users.  Mis-designed it would scale
badly on multi-threaded machines and involve lots of ugly locks.
I don't want to consider the impacts if one had to pass packets between 
processes...
I don't advocate a solution like this (I'll live with the dropped packets),
but I think it's worth making people aware that they might see mis-directed
packets get dropped.

> Maybe I misunderstand your point -
> but the client address *is* returned? Admittedly its wrapped in a
> BIO_ADDR, but its easy to get the underlying "raw" address using
> BIO_ADDR_rawaddress():

> Why isn't recvfrom() suitable (which is what the code currently uses to
> get the address)?

The address of the remote client is returned ("getpeername()") by 
DTLSv1_listen().
That's all that recvfrom() gives you.

recvfrom() was a reasonable API for SunOS 3.x machines with a single 10Mb/s
interface with a single IPv4 address.  I loved all that at the time...
But it doesn't work that well when we might have a dozen different kind of
IPv6 addresses on each virtual interface.

The address that I'm talking about needing is the one the remote client used
to reach us.  That's the destination IP of the incoming packet ("getsockname()" 
in TCP speak).

With TCP this is never an issue because the kernel creates the new socket and
copies the right stuff in for us when it creates the socket.

With UDP, the source address for outgoing packets needs to match or the
client may get a response from an address that it didn't connect to.  Worse,
there might be firewalls or policy routing that would cause the packet to
disappear or get routed differently.  In my application, I definitely dealing
with connections over IPv6 Link-Local addresses with a multitude of virtual
links.

In your code example:
bind(client_fd, _addr, sizeof(struct sockaddr_in6));

server_addr has to be set from the destination address of the incoming
packet, it's not a global that the admin set, or the SIP negotiated.

In the bad old days, this meant opening a socket for every interface on the
machine, and re-reading the list of interfaces based upon some heuristic.
(routing socket, SIGHUP, ...)

Even getting a list of interfaces (and their addresses) is itself a
OS-dependant activity!  And, if you use the old BSD interface on Linux,
you'll miss a bunch of interfaces, because the Linux kernel people thought
that it would confuse BSD APIs if interfaces were returned that the BSD
interface didn't create.  So you can't even win there.

The IPv6 API gives us recvmsg() and ipi6_pktinfo, which makes it all sane.
But, we never got a standard interface for IPv4: Linux uses something that
looks identical to IPv6, and BSD has something with slightly different names.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Matt Caswell]

On 16/01/18 15:32, Michael Richardson wrote:
> 
> a) when the existing FD is connect(2) any future traffic to the bound port
>will get rejected with no port.  So the application really has to open a
>new socket first.
>The application can do this two ways: it can open a new socket on which to 
> receive
>new connections, or it can open a new socket on which to communicate with
>the new client.The second method is better for reason (b) below.
>Either way, it socket to communicate with the client needs to be bind(2)
>to the address that the client used to communicate with the server, and
>DTLSv1_listen() didn't collect or return that information.

The second way is what is intended. Maybe I misunderstand your point -
but the client address *is* returned? Admittedly its wrapped in a
BIO_ADDR, but its easy to get the underlying "raw" address using
BIO_ADDR_rawaddress():

https://www.openssl.org/docs/man1.1.0/crypto/BIO_ADDR_rawaddress.html

i.e. call BIO_ADDR_rawaddress() on the BIO_ADDR returned by
DTLSv1_listen() and then do something like this:

 /* Handle client connection */
 int client_fd = socket(AF_INET6, SOCK_DGRAM, 0);
 bind(client_fd, _addr, sizeof(struct sockaddr_in6));
 connect(client_fd, _addr, sizeof(struct sockaddr_in6));
 /* Set new fd and set BIO to connected */
 BIO *cbio = SSL_get_rbio(ssl);
 BIO_set_fd(cbio, client_fd, BIO_NOCLOSE);
 BIO_ctrl(cbio, BIO_CTRL_DGRAM_SET_CONNECTED, 0, _addr);
 /* Finish handshake */
 SSL_accept(ssl);

> 
> b) the existing FD might have additional packets from other clients. This
>argues for opening a new socket for the new client, and leaving the queue
>on the existing FD.

Which is what I recommend.


> I absolutely need to have recvmsg()/sendmsg() in the bss_dgram.c in order to
> get the destination address used.   This IPv6 code is portable, since the RFC
> API says how to do it.

Why isn't recvfrom() suitable (which is what the code currently uses to
get the address)?

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

please see https://github.com/openssl/openssl/pull/5024

mattcaswell asks on github:
mattcaswell> I am unclear about the underlying premise of this PR:

mcr> This patch refactors the DTLSv1_listen() to create an
mcr> alternative API that is called DTLSv1_accept().
mcr> DTLSv1_accept() is useable by programs that need to treat
mcr> DTLS interfaces in a way similar to TCP: new connections
mcr> must be accepted, and new sockets created.

mattcaswell> Your going to give more justification than this. Why is it
mattcaswell> that DTLSv1_listen() is not appropriate for your use case?

As I understand using DTLSv1_listen(), one does the following:
  1) open a UDP socket, bind(2) it appropriately.
 {in an RTP context, one might already know the remote port numbers, and
 one could connect(2) it already. In the CoAP case, that certainly is not
 the case}
 Put the socket into an SSL, do appropriate blocking or non-blocking
 event handling in application.

  2) call DTLSv1_listen() when there is traffic.
 DTLSv1_listen() will process (via peek) the first packet in the socket.
 If it's a Client Hello without a cookie, then a Hello Verify is sent
 back (%).  If it ate the packet, then it loops until it find something
 it can't handle or runs out of packets.

  3) DTLSv1_listen(), when it finds a Client Hello with a cookie, marks the
 provided SSL as having transitioned to a state where things can start,
 and it returns 1, along with the BIO_ADDR of the newly Verify Hello'ed 
client.

  4) the application is now expected to connect() the FD to the BIO_ADDR,
 and call SSL_accept(), and then to proceed with SSL_read()/SSL_write(), 
etc.

Perhaps I've gotten something wrong with this process.

This flow is entirely appropriate for a RTP user, but for a CoAP server there
are a number of problems:

a) when the existing FD is connect(2) any future traffic to the bound port
   will get rejected with no port.  So the application really has to open a
   new socket first.
   The application can do this two ways: it can open a new socket on which to 
receive
   new connections, or it can open a new socket on which to communicate with
   the new client.The second method is better for reason (b) below.
   Either way, it socket to communicate with the client needs to be bind(2)
   to the address that the client used to communicate with the server, and
   DTLSv1_listen() didn't collect or return that information.

b) the existing FD might have additional packets from other clients. This
   argues for opening a new socket for the new client, and leaving the queue
   on the existing FD.

c) the DTLSv1_listen() uses the SSL* (and associated CTX) that is provided to
   it for callbacks, and cookie verification.  It modifies the state of that
   SSL* to continue the transaction.
   I think that the roles should be split up.

also, from point (2) above:
(%) - the send that DTLSv1_listen() depends upon the socket having been
bind(2) with a non-INADDR_ANY/IN6ADDR_ANY_INIT IP address, or that the
system in question has only a single IP address.  This is because the
write that is done relies upon the kernel to pick the right source
address,  which appears to be easy for IPv4 with a single interface, but
trivially can fail for IPv6 even with a single interface due to
temporary, stable-private, and link-local addresses.


DTLSv1_accept() takes two SSL*.  The first is used for cookie verification,
while the second is filled in with a new FD that has been bind/connect to the
client and state advanced to be ready for SSL_accept().  It also returns the
same BIO_ADDR for the client, but that could be removed as it can trivially
be retrieved from the new SSL*.

mattcaswell> In any case the PR as it currently stands is a very long way
mattcaswell> off being acceptable:

I totally agree, but I had to post something to start the conversation.

mattcaswell> * As you point out the use of the POSIX socket APIs is
mattcaswell> unacceptable and is at the wrong level of abstraction. I
mattcaswell> might perhaps expect to see this sort of thing in the BIO
mattcaswell> layer.

a) I could move the socket creation code into BIO layer, a new BIO_ctrl method
   could be created to "duplicate" the BIO.  This would probably eliminate
   having to expose BIO_ADDR_sockaddr{,_size} from libcrypto->libssl.

b) creation of a new socket could be a new callback.

c) DTLSv1_accept() could return at:
   "now set up a socket based upon the original rbio's peer/addr"
   as all of the subsequent operations could be done by the application given
 BIO_dgram_get_peer(rbio, client) and BIO_dgram_get_addr(rbio, ouraddr)

d) a combination of (a) and (c), where the duplication code is provided by
   the BIO layer, but the application could do something different if it
   needed to.

My preference is for (d), because I think that it's common code and 

[openssl-dev] DTLS "accept" functionality

[Michael Richardson]

I have been working since mid-November in my "copious spare time" to bring
DTLS support into ruby-openssl in order to bring DTLS into the Rails "David"
CoAP server.

DTLS_listen() seems entirely focused on single-use situations like in RTP,
where only a single connection (single DTLS session) is expected. If used
in CoAP situation, there are a number of race conditions that make it
hard to use correctly.   I wrote another email about that, which I think did
not get to the list, which I can resend.

I have preserved DLTSv1_listen() functionality, refactoring most of it
into DTLSv1_anwerHello(), and then adding DTLSv1_accept() on top of it.

Unfortunately I was also forced to delve into dgram_bss.c in order to bring
some additional information out; stuff which is rather OS dependant for IPv4,
and which perhaps would be better done in the application somehow.

I'm looking for advice.

Also, I found it difficult to find the right incantation to get a static
build; I noticed finally that my test/* programs were linking against the
libssl that was in my /lib, rather than the code I was testing.  I suggest
that this be captured into a ./Configure option.  I used:

 ./Configure no-shared --debug linux-x86_64

"no-dso" seemed like it ought to help, but it made things worse...

I hope that I added the new exposed symbols correctly.
I have yet to validate the complete david/coap/ruby-openssl/dtls
functionality, but I wanted to post this sooner for review.


https://github.com/openssl/openssl/pull/5024 says:

This patch refactors the DTLSv1_listen() to create an alternative API that is
called DTLSv1_accept().

DTLSv1_accept() is useable by programs that need to treat DTLS interfaces in
a way similar to TCP: new connections must be accepted, and new sockets
created.

There are a number of changes included here:

1. dgram_write() and dgram_read() now use sendmsg(2) and recvmsg(2) in order to 
set and collect the local address used in the datagram.  This allows a socket 
to bound to ::, while still sending traffic correctly from the address that the 
other peer used. The IPv6 version of this code is according to rfc3542 API, but 
the IPv4 of the code is Linux specific and needs to be either abstracted and 
translated for *BSD and Windows, or IPv6 mapped IPv4 sockets could be used.
2. a new BIO control SET_ADDR and GET_ADDR are added, and if the address is not 
set then it pulls it out of the socket using getsockname(2).
3. DTLSv1_accept() accepts a second SSL* on which new connections are setup. A 
new socket is set up using the addresses from the received message and it is 
inserted into the BIO. There is a race condition during setup which turned out 
to be unavoidable: between the bind(2) and the connect(2), the new socket could 
have the same address as the "listen" socket, and additional hello packets 
could arrive on the wrong socket.  Such packets will hopefully be dropped as 
garbage. It was thought that connect(2) could be called before bind(2), but 
that seems to cause the kernel to allocate a local address for the new socket 
(a random port), which the subsequent bind(2) can not seem to change.
4. the use of POSIX socket APIs inside this code is likely inappropriate and 
this routine should be split up in some better way so that socket activities 
can be done by the application, using the correct abstractions for the OS.
5. a new test case dtlsaccepttest was created.  It uses fork() and also calls 
system() on "openssl s_client". Probably it should just call code internally, 
but apps/* is not in a library form that can be used. Perhaps this use is 
acceptable.  Other test functions just use canned packets in/out, but since 
this is testing the creation/adaption of socket code, real sockets would seem 
to be necessary.  Probably this test case should be disabled on non-Unix 
platforms.
6. routines BIO_ADDR_sockaddr and BIO_ADDR_sockaddr_size exposed from libcrypto 
to libssl.  There might be a better way to do this, perhaps a BIO_CTRL would be 
better?



--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] DTLS in multi-thread and concurrent connection acceptance environment

[Angus Robertson - Magenta Systems Ltd]

> I don't know if anyone has ever created any metrics on how far it 
> can be scaled. I've certainly not seen it if they have. But there
> are no knownlimitations on this approach (this is the intended
> way to do things).

Our Delphi OpenSSL implementation on Windows mostly uses a single
thread and event driven code, although Windows itself uses a thread per
connection. But we don't support DTLS.  

I did some testing last year with simple SSL TCP/IP client and server
on Windows 10, and had 2,000 simultaneous SSL sessions running on the
same PC, always thought client versions of Windows supported far fewer
sessions.

The main limitation during testing with a single thread was the set-up
time for SSL, there is a limit of how many new sessions can be started
per second.  My test was starting 100 sessions per second, and about
20% failed initially, but succeeded later on retries. 

I used my own applications for testing, ComCap5 and ComGen5 from
https://www.magsys.co.uk/comcap/ 

ComGen is a TCP/UDP session data generator, configurable for multiple
IPs and ports, and volume of sessions.  

Angus
  

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS is not sending alert in case of BAD CCS

[Matt Caswell]

https://github.com/openssl/openssl/pull/3009

On 21/03/17 15:24, Raja ashok wrote:
> Hi All,
> 
>  
> 
> Looks like there is a typo mistake in dtls1_read_bytes, because of this
> alert is not send for bad CCS.
> 
>  
> 
> In dtls1_read_bytes, incase of bad change cipher spec we are setting
> alert code (SSL_AD_ILLEGAL_PARAMETER) to variable “i” and doing “goto
> err”. I feel we are trying to send alert in this case, so we need to set
> the alert in “al” and do “goto f_err”.
> 
>  
> 
> In case of TLS we are sending alert.
> 
>  
> 
> Note : I am referring 1.0.2.k version of OpenSSL
> 
>  
> 
> Regards,
> 
> Ashok
> 
>  
> 
> 
> 
> Company_logo
> 
> Raja Ashok V K
> Huawei Technologies
> Bangalore, India
> http://www.huawei.com
> 
> 
> 
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或
> 群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）
> 本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
> 
>  
> 
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] DTLS is not sending alert in case of BAD CCS

[Raja ashok]

Hi All,

Looks like there is a typo mistake in dtls1_read_bytes, because of this alert 
is not send for bad CCS.

In dtls1_read_bytes, incase of bad change cipher spec we are setting alert code 
(SSL_AD_ILLEGAL_PARAMETER) to variable “i” and doing “goto err”. I feel we are 
trying to send alert in this case, so we need to set the alert in “al” and do 
“goto f_err”.

In case of TLS we are sending alert.

Note : I am referring 1.0.2.k version of OpenSSL

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS encrypt-then-mac

[David Woodhouse]

On Thu, 2016-10-13 at 23:48 +0100, Matt Caswell wrote:
> 
> > Any dissenting opinions?
> 
> Not from me. It's broken. Lets fix it.

Thanks. https://github.com/openssl/openssl/pull/1705 updated accordingly.

With that fixed, I think https://github.com/openssl/openssl/pull/1666
is now ready to be merged too (it contains the fixes from #1705, which
it depends on).

The only bit I wasn't sure about in #1666 was the addition of the DTLS
cipher tests to ssl_test_old — which is redundant now I've written a
completely new test to do an MTU torture test on every cipher suite
(both with an without EtM, for CBC suites). So I took it out.

But I've submitted that part separately anyway, since part of it might
be useful — in order for the test recipe to *get* the list of DTLS
ciphersuites, I had to make 'openssl ciphers DTLSv1' work. Which might
be worth keeping, although it wants careful review:
https://github.com/openssl/openssl/pull/1710

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS encrypt-then-mac

[Matt Caswell]

On 13/10/16 11:45, David Woodhouse wrote:
> ... is broken in 1.1. We negotiate it, then don't actually *do* it.
> 
> https://github.com/openssl/openssl/pull/1705 contains a patch to
> disable it unconditionally for DTLS, on both server and client.
> 
> In that same PR there's also a patch to actually implement EtM for DTLS
> — so that if it ever *stops* being disabled, it would actually work.
> That second patch is tested (by reverting the first) against a GnuTLS
> server both with and without EtM.
> 
> What remains is to have a conversation about how, if ever, we can turn
> EtM back on again.
> 
> There are a few mitigating factors:
>  • OpenSSL 1.1 is the only version which has this problem.
>  • OpenSSL 1.1 supports DTLSv1.2 and AEAD ciphers, which disable EtM.
> 
> However, the problem still exists for applications using OpenSSL 1.1
> with DTLSv1.0, where they *will* end up using a CBC cipher.
> 
> I don't think it makes much sense just to leave EtM disabled —
> depending on how you look at things, that's either not necessary (who
> cares about OpenSSL 1.1.0[ab]; just upgrade to 1.1.0c!), or not
> sufficient (1.1.0[ab] are still broken when talking to e.g. GnuTLS
> anyway, and *everyone* would need to stop doing DTLS+EtM).
> 
> So I think in the process of typing this mail, I've persuaded at least
> *myself* that the PR above should be refactored to include *only* the
> second patch; to *fix* EtM without disabling it.
> 
> Any dissenting opinions?

Not from me. It's broken. Lets fix it.

Matt


> 
> It really would be nice to have a way to disable EtM voluntarily
> though; especially for the DTLS_get_data_mtu() test cases that I've
> added in PR#1666.
> 
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS retransmission api

[Alfred E. Heggestad]

On 03/06/16 12:19, Matt Caswell wrote:



On 03/06/16 10:52, Alfred E. Heggestad wrote:

Hi Matt,

thanks for the suggested API and code. Please find below a suggested
patch that implements this new callback.


the patch is based on 1.0.2-dev from GIT:

   url:  git://git.openssl.org/openssl.git
   branch:   origin/OpenSSL_1_0_2-stable


I have renamed "timeout_duration" on purpose, since the units have
changed from "seconds" to "milliseconds".


Hi Alfred

Thanks for the submission. In order to ease the review process please
read this file for some guidance on how to submit patches:

https://github.com/openssl/openssl/blob/master/CONTRIBUTING

The preferred way is via github because it makes it much easier for us
to comment on the code in detail and provide feedback.

I've not looked at your code in detail yet (I'll wait until I see the
submission come in via github (or RT if you choose to go that way - see
CONTRIBUTING)). I'll make a few high-level points though:

- Because this is a new feature you need to create it from the master
branch in git not the 1.0.2 branch. 1.0.2 is a stable branch and only
receives bug fixes.

- We are currently focussing on the 1.1.0 release which is now in
feature freeze, so it may be a while before we get to look at it.

- All new features must have documentation with them. Take a look at the
existing pod files in the doc directory for some examples of our style.



thanks, I have created a new PR:


  https://github.com/openssl/openssl/pull/1160




/alfred
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS retransmission api

[Matt Caswell]

On 03/06/16 10:52, Alfred E. Heggestad wrote:
> Hi Matt,
> 
> thanks for the suggested API and code. Please find below a suggested
> patch that implements this new callback.
> 
> 
> the patch is based on 1.0.2-dev from GIT:
> 
>   url:  git://git.openssl.org/openssl.git
>   branch:   origin/OpenSSL_1_0_2-stable
> 
> 
> I have renamed "timeout_duration" on purpose, since the units have
> changed from "seconds" to "milliseconds".

Hi Alfred

Thanks for the submission. In order to ease the review process please
read this file for some guidance on how to submit patches:

https://github.com/openssl/openssl/blob/master/CONTRIBUTING

The preferred way is via github because it makes it much easier for us
to comment on the code in detail and provide feedback.

I've not looked at your code in detail yet (I'll wait until I see the
submission come in via github (or RT if you choose to go that way - see
CONTRIBUTING)). I'll make a few high-level points though:

- Because this is a new feature you need to create it from the master
branch in git not the 1.0.2 branch. 1.0.2 is a stable branch and only
receives bug fixes.

- We are currently focussing on the 1.1.0 release which is now in
feature freeze, so it may be a while before we get to look at it.

- All new features must have documentation with them. Take a look at the
existing pod files in the doc directory for some examples of our style.


Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS retransmission api

[Alfred E. Heggestad]

On 02/06/16 16:03, Matt Caswell wrote:



On 02/06/16 14:33, Alfred E. Heggestad wrote:



On 01/06/16 13:58, Matt Caswell wrote:



On 01/06/16 11:15, Alfred E. Heggestad wrote:

hi,

we are using DTLS from OpenSSL to implement DTLS-SRTP in our
product (Wire.com) .. The code and implementation works really well
and is very robust. We are using OpenSSL version 1.0.2g


since our product is deployed globally on mobile data networks,
we have quite variable latency and packetloss. The patch below
shows my working code, it has an initial retransmit timeout
of 400 ms which is incrementing by 10% for every re-trans.


obviously this patch cannot make it into the official tree.


but I would like to discuss with you guys the option to
add some kind of API for:

- Setting the initial RTO for DTLS (in milliseconds).
- Setting the retransmit policy for DTLS, i.e. should it
double or increment by X for every re-trans.


I think an API for that would be a great idea. Perhaps a callback could
be used so that you can set exactly the policy you want?



Thank you, Matt


I can work on a patch for this, if you guys can help me to define
the API.


I think we only need one CTRL api to set the next re-transmit
interval. then in the application code that calls this:

- DTLSv1_handle_timeout
- DTLSv1_get_timeout


can also call DTLS_set_retrans_interval(400)



I'm not sure I follow you. I was thinking something like:

int DTLS_set_timer_cb(SSL *s, int (*cb)(SSL *s, int timer));

Then where in the current code we have:

 dtls1_double_timeout(s);

We might instead do

 if(s->d1->timer_cb != NULL)
s->d1->timeout_duration = timer_cb(s, s->d1->timeout_duration);
 else
dtls1_double_timeout(s);


And in dtls1_start_timer() where we have:

 /* If timer is not set, initialize duration with 1 second */
 if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
 s->d1->timeout_duration = 1;
 }


Instead have:

 /* If timer is not set, initialize duration with 1 second */
 if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
 if (s->d1->timer_cb != NULL)
s->d1->timeout_duration = s->d1_timeout_cb(s, 0);
 else
 s->d1->timeout_duration = 1;
 }




Hi Matt,

thanks for the suggested API and code. Please find below a suggested
patch that implements this new callback.


the patch is based on 1.0.2-dev from GIT:

  url:  git://git.openssl.org/openssl.git
  branch:   origin/OpenSSL_1_0_2-stable


I have renamed "timeout_duration" on purpose, since the units have
changed from "seconds" to "milliseconds".





From e6c9fbe470ab1901010e90b727313ebc7875b40f Mon Sep 17 00:00:00 2001
From: "Alfred E. Heggestad" <a...@db.org>
Date: Fri, 3 Jun 2016 11:31:45 +0200
Subject: [PATCH] add support for DTLS callback for timeout value

---
 ssl/d1_lib.c | 45 +
 ssl/dtls1.h  |  9 +++--
 ssl/ssl.h|  4 
 3 files changed, 48 insertions(+), 10 deletions(-)

diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index ee78921..235635a 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -240,6 +240,8 @@ void dtls1_clear(SSL *s)
 unsigned int link_mtu;

 if (s->d1) {
+dtls_timer_cb *timer_cb = s->d1->timer_cb;
+
 unprocessed_rcds = s->d1->unprocessed_rcds.q;
 processed_rcds = s->d1->processed_rcds.q;
 buffered_messages = s->d1->buffered_messages;
@@ -252,6 +254,9 @@ void dtls1_clear(SSL *s)

 memset(s->d1, 0, sizeof(*(s->d1)));

+/* Restore the timer callback from previous state */
+s->d1->timer_cb = timer_cb;
+
 if (s->server) {
 s->d1->cookie_len = sizeof(s->d1->cookie);
 }
@@ -359,6 +364,8 @@ const SSL_CIPHER *dtls1_get_cipher(unsigned int u)

 void dtls1_start_timer(SSL *s)
 {
+struct timeval diff;
+
 #ifndef OPENSSL_NO_SCTP
 /* Disable timer for SCTP */
 if (BIO_dgram_is_sctp(SSL_get_wbio(s))) {
@@ -367,16 +374,24 @@ void dtls1_start_timer(SSL *s)
 }
 #endif

-/* If timer is not set, initialize duration with 1 second */
+/* If timer is not set, initialize duration with 1 second or
+ * a user-specified value if the timer callback is installed. */
 if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec == 0) {
-s->d1->timeout_duration = 1;
+
+if (s->d1->timer_cb != NULL)
+s->d1->timeout_duration_ms = s->d1->timer_cb(s, 1000);
+else
+s->d1->timeout_duration_ms = 1000;
 }

 /* Set timeout to current time */
 get_current_time(&(s->d1->next_timeout));

 /* Add duration to current time */
-s->d1->n

Re: [openssl-dev] DTLS retransmission api

[Matt Caswell]

On 02/06/16 14:33, Alfred E. Heggestad wrote:
> 
> 
> On 01/06/16 13:58, Matt Caswell wrote:
>>
>>
>> On 01/06/16 11:15, Alfred E. Heggestad wrote:
>>> hi,
>>>
>>> we are using DTLS from OpenSSL to implement DTLS-SRTP in our
>>> product (Wire.com) .. The code and implementation works really well
>>> and is very robust. We are using OpenSSL version 1.0.2g
>>>
>>>
>>> since our product is deployed globally on mobile data networks,
>>> we have quite variable latency and packetloss. The patch below
>>> shows my working code, it has an initial retransmit timeout
>>> of 400 ms which is incrementing by 10% for every re-trans.
>>>
>>>
>>> obviously this patch cannot make it into the official tree.
>>>
>>>
>>> but I would like to discuss with you guys the option to
>>> add some kind of API for:
>>>
>>> - Setting the initial RTO for DTLS (in milliseconds).
>>> - Setting the retransmit policy for DTLS, i.e. should it
>>>double or increment by X for every re-trans.
>>
>> I think an API for that would be a great idea. Perhaps a callback could
>> be used so that you can set exactly the policy you want?
>>
> 
> Thank you, Matt
> 
> 
> I can work on a patch for this, if you guys can help me to define
> the API.
> 
> 
> I think we only need one CTRL api to set the next re-transmit
> interval. then in the application code that calls this:
> 
> - DTLSv1_handle_timeout
> - DTLSv1_get_timeout
> 
> 
> can also call DTLS_set_retrans_interval(400)
> 

I'm not sure I follow you. I was thinking something like:

int DTLS_set_timer_cb(SSL *s, int (*cb)(SSL *s, int timer));

Then where in the current code we have:

dtls1_double_timeout(s);

We might instead do

if(s->d1->timer_cb != NULL)
s->d1->timeout_duration = timer_cb(s, s->d1->timeout_duration);
else
dtls1_double_timeout(s);


And in dtls1_start_timer() where we have:

/* If timer is not set, initialize duration with 1 second */
if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
s->d1->timeout_duration = 1;
}


Instead have:

/* If timer is not set, initialize duration with 1 second */
if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
if (s->d1->timer_cb != NULL)
s->d1->timeout_duration = s->d1_timeout_cb(s, 0);
else
s->d1->timeout_duration = 1;
}


...or something like that.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS retransmission api

[Alfred E. Heggestad]

On 01/06/16 13:58, Matt Caswell wrote:



On 01/06/16 11:15, Alfred E. Heggestad wrote:

hi,

we are using DTLS from OpenSSL to implement DTLS-SRTP in our
product (Wire.com) .. The code and implementation works really well
and is very robust. We are using OpenSSL version 1.0.2g


since our product is deployed globally on mobile data networks,
we have quite variable latency and packetloss. The patch below
shows my working code, it has an initial retransmit timeout
of 400 ms which is incrementing by 10% for every re-trans.


obviously this patch cannot make it into the official tree.


but I would like to discuss with you guys the option to
add some kind of API for:

- Setting the initial RTO for DTLS (in milliseconds).
- Setting the retransmit policy for DTLS, i.e. should it
   double or increment by X for every re-trans.


I think an API for that would be a great idea. Perhaps a callback could
be used so that you can set exactly the policy you want?



Thank you, Matt


I can work on a patch for this, if you guys can help me to define
the API.


I think we only need one CTRL api to set the next re-transmit
interval. then in the application code that calls this:

- DTLSv1_handle_timeout
- DTLSv1_get_timeout


can also call DTLS_set_retrans_interval(400)





in addition we have seen the code hit this assert
in production:


   /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */


so I would say it should be safe to remove it.


Hmthe question is why does it get there? It shouldn't.



I can try to reproduce this. We have seen that this assert was
executed, when the code was under quite heavy load and lots of traffic.




/alfred



Matt







Best Regards,

Alfred E. Heggestad
Berlin



--

diff -Naur openssl-1.0.2g/ssl/d1_lib.c openssl/ssl/d1_lib.c
--- openssl-1.0.2g/ssl/d1_lib.c2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/d1_lib.c2016-06-01 10:45:27.0 +0200
@@ -359,6 +359,8 @@

  void dtls1_start_timer(SSL *s)
  {
+struct timeval diff;
+
  #ifndef OPENSSL_NO_SCTP
  /* Disable timer for SCTP */
  if (BIO_dgram_is_sctp(SSL_get_wbio(s))) {
@@ -369,14 +371,17 @@

  /* If timer is not set, initialize duration with 1 second */
  if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
== 0) {
-s->d1->timeout_duration = 1;
+s->d1->timeout_duration = 0.400;
  }

  /* Set timeout to current time */
  get_current_time(&(s->d1->next_timeout));

  /* Add duration to current time */
-s->d1->next_timeout.tv_sec += s->d1->timeout_duration;
+diff.tv_sec  = 0;
+diff.tv_usec = 100*s->d1->timeout_duration;
+timeradd(>d1->next_timeout, , >d1->next_timeout);
+
  BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0,
   &(s->d1->next_timeout));
  }
@@ -441,7 +446,7 @@

  void dtls1_double_timeout(SSL *s)
  {
-s->d1->timeout_duration *= 2;
+s->d1->timeout_duration *= 1.10;
  if (s->d1->timeout_duration > 60)
  s->d1->timeout_duration = 60;
  dtls1_start_timer(s);
diff -Naur openssl-1.0.2g/ssl/d1_pkt.c openssl/ssl/d1_pkt.c
--- openssl-1.0.2g/ssl/d1_pkt.c2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/d1_pkt.c2016-03-08 14:39:44.0 +0100
@@ -1502,7 +1502,7 @@
   * will happen with non blocking IO
   */
  if (s->s3->wbuf.left != 0) {
-OPENSSL_assert(0);  /* XDTLS: want to see if we ever get
here */
+/*OPENSSL_assert(0);*/  /* XDTLS: want to see if we ever
get here */
  return (ssl3_write_pending(s, type, buf, len));
  }

diff -Naur openssl-1.0.2g/ssl/dtls1.h openssl/ssl/dtls1.h
--- openssl-1.0.2g/ssl/dtls1.h2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/dtls1.h2016-03-08 14:39:44.0 +0100
@@ -225,8 +225,8 @@
   * Indicates when the last handshake msg or heartbeat sent will
timeout
   */
  struct timeval next_timeout;
-/* Timeout duration */
-unsigned short timeout_duration;
+/* Timeout duration in Seconds */
+double timeout_duration;
  /*
   * storage for Alert/Handshake protocol data received but not yet
   * processed by ssl3_read_bytes:



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS retransmission api

[Matt Caswell]

On 01/06/16 11:15, Alfred E. Heggestad wrote:
> hi,
> 
> we are using DTLS from OpenSSL to implement DTLS-SRTP in our
> product (Wire.com) .. The code and implementation works really well
> and is very robust. We are using OpenSSL version 1.0.2g
> 
> 
> since our product is deployed globally on mobile data networks,
> we have quite variable latency and packetloss. The patch below
> shows my working code, it has an initial retransmit timeout
> of 400 ms which is incrementing by 10% for every re-trans.
> 
> 
> obviously this patch cannot make it into the official tree.
> 
> 
> but I would like to discuss with you guys the option to
> add some kind of API for:
> 
> - Setting the initial RTO for DTLS (in milliseconds).
> - Setting the retransmit policy for DTLS, i.e. should it
>   double or increment by X for every re-trans.

I think an API for that would be a great idea. Perhaps a callback could
be used so that you can set exactly the policy you want?

> 
> 
> in addition we have seen the code hit this assert
> in production:
> 
> 
>   /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */
> 
> 
> so I would say it should be safe to remove it.

Hmthe question is why does it get there? It shouldn't.


Matt


> 
> 
> 
> 
> Best Regards,
> 
> Alfred E. Heggestad
> Berlin
> 
> 
> 
> -- 
> 
> diff -Naur openssl-1.0.2g/ssl/d1_lib.c openssl/ssl/d1_lib.c
> --- openssl-1.0.2g/ssl/d1_lib.c2016-03-01 14:35:53.0 +0100
> +++ openssl/ssl/d1_lib.c2016-06-01 10:45:27.0 +0200
> @@ -359,6 +359,8 @@
> 
>  void dtls1_start_timer(SSL *s)
>  {
> +struct timeval diff;
> +
>  #ifndef OPENSSL_NO_SCTP
>  /* Disable timer for SCTP */
>  if (BIO_dgram_is_sctp(SSL_get_wbio(s))) {
> @@ -369,14 +371,17 @@
> 
>  /* If timer is not set, initialize duration with 1 second */
>  if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec
> == 0) {
> -s->d1->timeout_duration = 1;
> +s->d1->timeout_duration = 0.400;
>  }
> 
>  /* Set timeout to current time */
>  get_current_time(&(s->d1->next_timeout));
> 
>  /* Add duration to current time */
> -s->d1->next_timeout.tv_sec += s->d1->timeout_duration;
> +diff.tv_sec  = 0;
> +diff.tv_usec = 100*s->d1->timeout_duration;
> +timeradd(>d1->next_timeout, , >d1->next_timeout);
> +
>  BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0,
>   &(s->d1->next_timeout));
>  }
> @@ -441,7 +446,7 @@
> 
>  void dtls1_double_timeout(SSL *s)
>  {
> -s->d1->timeout_duration *= 2;
> +s->d1->timeout_duration *= 1.10;
>  if (s->d1->timeout_duration > 60)
>  s->d1->timeout_duration = 60;
>  dtls1_start_timer(s);
> diff -Naur openssl-1.0.2g/ssl/d1_pkt.c openssl/ssl/d1_pkt.c
> --- openssl-1.0.2g/ssl/d1_pkt.c2016-03-01 14:35:53.0 +0100
> +++ openssl/ssl/d1_pkt.c2016-03-08 14:39:44.0 +0100
> @@ -1502,7 +1502,7 @@
>   * will happen with non blocking IO
>   */
>  if (s->s3->wbuf.left != 0) {
> -OPENSSL_assert(0);  /* XDTLS: want to see if we ever get
> here */
> +/*OPENSSL_assert(0);*/  /* XDTLS: want to see if we ever
> get here */
>  return (ssl3_write_pending(s, type, buf, len));
>  }
> 
> diff -Naur openssl-1.0.2g/ssl/dtls1.h openssl/ssl/dtls1.h
> --- openssl-1.0.2g/ssl/dtls1.h2016-03-01 14:35:53.0 +0100
> +++ openssl/ssl/dtls1.h2016-03-08 14:39:44.0 +0100
> @@ -225,8 +225,8 @@
>   * Indicates when the last handshake msg or heartbeat sent will
> timeout
>   */
>  struct timeval next_timeout;
> -/* Timeout duration */
> -unsigned short timeout_duration;
> +/* Timeout duration in Seconds */
> +double timeout_duration;
>  /*
>   * storage for Alert/Handshake protocol data received but not yet
>   * processed by ssl3_read_bytes:
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] DTLS retransmission api

[Alfred E. Heggestad]

hi,

we are using DTLS from OpenSSL to implement DTLS-SRTP in our
product (Wire.com) .. The code and implementation works really well
and is very robust. We are using OpenSSL version 1.0.2g


since our product is deployed globally on mobile data networks,
we have quite variable latency and packetloss. The patch below
shows my working code, it has an initial retransmit timeout
of 400 ms which is incrementing by 10% for every re-trans.


obviously this patch cannot make it into the official tree.


but I would like to discuss with you guys the option to
add some kind of API for:

- Setting the initial RTO for DTLS (in milliseconds).
- Setting the retransmit policy for DTLS, i.e. should it
  double or increment by X for every re-trans.


in addition we have seen the code hit this assert
in production:


  /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */


so I would say it should be safe to remove it.




Best Regards,

Alfred E. Heggestad
Berlin



--

diff -Naur openssl-1.0.2g/ssl/d1_lib.c openssl/ssl/d1_lib.c
--- openssl-1.0.2g/ssl/d1_lib.c 2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/d1_lib.c2016-06-01 10:45:27.0 +0200
@@ -359,6 +359,8 @@

 void dtls1_start_timer(SSL *s)
 {
+struct timeval diff;
+
 #ifndef OPENSSL_NO_SCTP
 /* Disable timer for SCTP */
 if (BIO_dgram_is_sctp(SSL_get_wbio(s))) {
@@ -369,14 +371,17 @@

 /* If timer is not set, initialize duration with 1 second */
 if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec == 0) {
-s->d1->timeout_duration = 1;
+s->d1->timeout_duration = 0.400;
 }

 /* Set timeout to current time */
 get_current_time(&(s->d1->next_timeout));

 /* Add duration to current time */
-s->d1->next_timeout.tv_sec += s->d1->timeout_duration;
+diff.tv_sec  = 0;
+diff.tv_usec = 100*s->d1->timeout_duration;
+timeradd(>d1->next_timeout, , >d1->next_timeout);
+
 BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0,
  &(s->d1->next_timeout));
 }
@@ -441,7 +446,7 @@

 void dtls1_double_timeout(SSL *s)
 {
-s->d1->timeout_duration *= 2;
+s->d1->timeout_duration *= 1.10;
 if (s->d1->timeout_duration > 60)
 s->d1->timeout_duration = 60;
 dtls1_start_timer(s);
diff -Naur openssl-1.0.2g/ssl/d1_pkt.c openssl/ssl/d1_pkt.c
--- openssl-1.0.2g/ssl/d1_pkt.c 2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/d1_pkt.c2016-03-08 14:39:44.0 +0100
@@ -1502,7 +1502,7 @@
  * will happen with non blocking IO
  */
 if (s->s3->wbuf.left != 0) {
-OPENSSL_assert(0);  /* XDTLS: want to see if we ever get here */
+/*OPENSSL_assert(0);*/  /* XDTLS: want to see if we ever get here 
*/
 return (ssl3_write_pending(s, type, buf, len));
 }

diff -Naur openssl-1.0.2g/ssl/dtls1.h openssl/ssl/dtls1.h
--- openssl-1.0.2g/ssl/dtls1.h  2016-03-01 14:35:53.0 +0100
+++ openssl/ssl/dtls1.h 2016-03-08 14:39:44.0 +0100
@@ -225,8 +225,8 @@
  * Indicates when the last handshake msg or heartbeat sent will timeout
  */
 struct timeval next_timeout;
-/* Timeout duration */
-unsigned short timeout_duration;
+/* Timeout duration in Seconds */
+double timeout_duration;
 /*
  * storage for Alert/Handshake protocol data received but not yet
  * processed by ssl3_read_bytes:


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Matt Caswell]

On 17/05/16 17:43, Rajeswari K wrote:
> Hi Matt,
> 
> Can you share s3_srvr.c file which is based on 1.1.0 release where DTLS
> session resumption works? I tried downloading 1.1.0-pre5 but i didnt see
> any file related with s3_srvr.c. 

See the tls_process_client_hello() function in ssl/statem/statem_srvr.c,
around line 1240.

Matt


> 
> Thanks,
> Rajeswari.
> 
> On Mon, May 16, 2016 at 11:20 AM, Rajeswari K  > wrote:
> 
> Hi Matt,
> 
> Yes, i tested with your patch. Honestly, before writing to
> openssl-dev team, i tried session resumption with moving the version
> just like what you gave as patch. But, still session resumption
> didn't work for me. Am debugging same at openssl front. 
> 
> Just to confirm on the issue, i tried hardcoding s->version and
> s->method with DTLSv1 just after calling SSL_new() followed by
> SSL_clear(). Then Session resumption worked as expected. 
> 
> So, updation of s->version during handshake and updation of
> s->session->version has some relation which am trying to find out. 
> 
> I was looking at updation of s->session->version during handshake
> when the version is DTLS_ANY_VERSION. Will check and update you on
> my findings if any. 
> 
> Thanks,
> Rajeswari.
> 
> 
> On Fri, May 13, 2016 at 11:16 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 13/05/16 18:33, Rajeswari K wrote:
> > Hi Matt,
> >
> > Thanks for the response.
> >
> > But, this fix doesn't perform session resumption.
> 
> Did you try the patch?
> 
> As you pointed out we hit the following line:
> 
> if (i == 1 && s->version == s->session->ssl_version) {
> /* previous
>
> * session */
> 
> The version from the SSL object and the version from the session
> do not
> match and that is why session resumption does not take place.
> 
> The reason that the versions do not match is because version
> negotiation
> takes place *after* this check. So at this point s->version equals
> DTLS_ANY_VERSION. My patch moves the version negotiation to
> before the
> above test so that s->version should now be equal to DTLSv1, and
> therefore should be the same as in s->session->ssl_version, and
> session
> resumption should be successful.
> 
> Matt
> 
> 
> 
> >
> > Thanks,
> > Rajeswari.
> >
> > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell  
> > >> wrote:
> >
> >
> >
> > On 10/05/16 18:34, Rajeswari K wrote:
> > > Hello openssl-dev team,
> > >
> > > Having query regarding DTLS session resumption when
> configured SSL_CTX
> > > with DTLS_ANY_VERSION.
> > >
> > > When we select SSL_CTX with DTLS_ANY_VERSION, method
> will be of
> > > DTLS_Server_method(), which will have ssl_ctx->version
> as 0xFEFD to
> > > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> > >
> > > During handshake, we landed on to version DTLS1.0.i.e.
> > > s->session->version holds 0xFEFF.
> > >
> > > In order to perform session resumption, we derived new
> SSL structure
> > > from global ssl_ctx using SSL_new() and tried performing ssl
> > handshake.
> > >
> > > With the below logic,
> > > else {
> > > i = ssl_get_prev_session(s, p, j, d + n);
> > > /*
> > >  * Only resume if the session's version matches
> the negotiated
> > >  * version.
> > >  * RFC 5246 does not provide much useful advice
> on resumption
> > >  * with a different protocol version. It doesn't
> forbid it but
> > >  * the sanity of such behaviour would be
> questionable.
> > >  * In practice, clients do not accept a version
> mismatch and
> > >  * will abort the handshake with an error.
> > >  */
> > > if (i == 1 && s->version ==
> s->session->ssl_version) { /*
> > previous
> > > 
>*
> > session */
> > > s->hit = 1;
> > > } else if (i == -1)
> > > goto err;
> > > else {

Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Rajeswari K]

Hi Matt,

Can you share s3_srvr.c file which is based on 1.1.0 release where DTLS
session resumption works? I tried downloading 1.1.0-pre5 but i didnt see
any file related with s3_srvr.c.

Thanks,
Rajeswari.

On Mon, May 16, 2016 at 11:20 AM, Rajeswari K 
wrote:

> Hi Matt,
>
> Yes, i tested with your patch. Honestly, before writing to openssl-dev
> team, i tried session resumption with moving the version just like what you
> gave as patch. But, still session resumption didn't work for me. Am
> debugging same at openssl front.
>
> Just to confirm on the issue, i tried hardcoding s->version and s->method
> with DTLSv1 just after calling SSL_new() followed by SSL_clear(). Then
> Session resumption worked as expected.
>
> So, updation of s->version during handshake and updation of
> s->session->version has some relation which am trying to find out.
>
> I was looking at updation of s->session->version during handshake when the
> version is DTLS_ANY_VERSION. Will check and update you on my findings if
> any.
>
> Thanks,
> Rajeswari.
>
>
> On Fri, May 13, 2016 at 11:16 PM, Matt Caswell  wrote:
>
>>
>>
>> On 13/05/16 18:33, Rajeswari K wrote:
>> > Hi Matt,
>> >
>> > Thanks for the response.
>> >
>> > But, this fix doesn't perform session resumption.
>>
>> Did you try the patch?
>>
>> As you pointed out we hit the following line:
>>
>> if (i == 1 && s->version == s->session->ssl_version) { /* previous
>> * session
>> */
>>
>> The version from the SSL object and the version from the session do not
>> match and that is why session resumption does not take place.
>>
>> The reason that the versions do not match is because version negotiation
>> takes place *after* this check. So at this point s->version equals
>> DTLS_ANY_VERSION. My patch moves the version negotiation to before the
>> above test so that s->version should now be equal to DTLSv1, and
>> therefore should be the same as in s->session->ssl_version, and session
>> resumption should be successful.
>>
>> Matt
>>
>>
>>
>> >
>> > Thanks,
>> > Rajeswari.
>> >
>> > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell > > > wrote:
>> >
>> >
>> >
>> > On 10/05/16 18:34, Rajeswari K wrote:
>> > > Hello openssl-dev team,
>> > >
>> > > Having query regarding DTLS session resumption when configured
>> SSL_CTX
>> > > with DTLS_ANY_VERSION.
>> > >
>> > > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
>> > > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD
>> to
>> > > support both the versions (i.e. DTLS1.0 and DTLS1.2).
>> > >
>> > > During handshake, we landed on to version DTLS1.0.i.e.
>> > > s->session->version holds 0xFEFF.
>> > >
>> > > In order to perform session resumption, we derived new SSL
>> structure
>> > > from global ssl_ctx using SSL_new() and tried performing ssl
>> > handshake.
>> > >
>> > > With the below logic,
>> > > else {
>> > > i = ssl_get_prev_session(s, p, j, d + n);
>> > > /*
>> > >  * Only resume if the session's version matches the
>> negotiated
>> > >  * version.
>> > >  * RFC 5246 does not provide much useful advice on
>> resumption
>> > >  * with a different protocol version. It doesn't forbid
>> it but
>> > >  * the sanity of such behaviour would be questionable.
>> > >  * In practice, clients do not accept a version mismatch
>> and
>> > >  * will abort the handshake with an error.
>> > >  */
>> > > if (i == 1 && s->version == s->session->ssl_version) { /*
>> > previous
>> > > *
>> > session */
>> > > s->hit = 1;
>> > > } else if (i == -1)
>> > > goto err;
>> > > else {  /* i == 0 */
>> > >
>> > > if (!ssl_get_new_session(s, 1))
>> > > goto err;
>> > > }
>> > >
>> > > Since s->version is with 0xFEFD and s->session->ssl_version is
>> 0xFEFF,
>> > > we always try for new session and wont land on to session
>> resumption
>> > > though client has sent the  session_id.
>> > >
>> > > Is this intended behaviour? Please clarify.
>> >
>> >
>> > No. This appears to be a bug introduced by commit 03d14f588734 in
>> > November 2014.
>> >
>> > The real problem though is that the DTLS version negotiation is
>> > happening too late - after session resumption. Interestingly this
>> only
>> > seems to be a problem in 1.0.2. In 1.1.0 this is working correctly
>> (the
>> > version negotiation logic has been substantially rewritten in the
>> new
>> > version).
>> >
>> > Please could you try out the attached patch? Let 

Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Rajeswari K]

Hi Matt,

Yes, i tested with your patch. Honestly, before writing to openssl-dev
team, i tried session resumption with moving the version just like what you
gave as patch. But, still session resumption didn't work for me. Am
debugging same at openssl front.

Just to confirm on the issue, i tried hardcoding s->version and s->method
with DTLSv1 just after calling SSL_new() followed by SSL_clear(). Then
Session resumption worked as expected.

So, updation of s->version during handshake and updation of
s->session->version has some relation which am trying to find out.

I was looking at updation of s->session->version during handshake when the
version is DTLS_ANY_VERSION. Will check and update you on my findings if
any.

Thanks,
Rajeswari.


On Fri, May 13, 2016 at 11:16 PM, Matt Caswell  wrote:

>
>
> On 13/05/16 18:33, Rajeswari K wrote:
> > Hi Matt,
> >
> > Thanks for the response.
> >
> > But, this fix doesn't perform session resumption.
>
> Did you try the patch?
>
> As you pointed out we hit the following line:
>
> if (i == 1 && s->version == s->session->ssl_version) { /* previous
> * session
> */
>
> The version from the SSL object and the version from the session do not
> match and that is why session resumption does not take place.
>
> The reason that the versions do not match is because version negotiation
> takes place *after* this check. So at this point s->version equals
> DTLS_ANY_VERSION. My patch moves the version negotiation to before the
> above test so that s->version should now be equal to DTLSv1, and
> therefore should be the same as in s->session->ssl_version, and session
> resumption should be successful.
>
> Matt
>
>
>
> >
> > Thanks,
> > Rajeswari.
> >
> > On Wed, May 11, 2016 at 2:56 PM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 10/05/16 18:34, Rajeswari K wrote:
> > > Hello openssl-dev team,
> > >
> > > Having query regarding DTLS session resumption when configured
> SSL_CTX
> > > with DTLS_ANY_VERSION.
> > >
> > > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> > > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> > > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> > >
> > > During handshake, we landed on to version DTLS1.0.i.e.
> > > s->session->version holds 0xFEFF.
> > >
> > > In order to perform session resumption, we derived new SSL
> structure
> > > from global ssl_ctx using SSL_new() and tried performing ssl
> > handshake.
> > >
> > > With the below logic,
> > > else {
> > > i = ssl_get_prev_session(s, p, j, d + n);
> > > /*
> > >  * Only resume if the session's version matches the
> negotiated
> > >  * version.
> > >  * RFC 5246 does not provide much useful advice on
> resumption
> > >  * with a different protocol version. It doesn't forbid it
> but
> > >  * the sanity of such behaviour would be questionable.
> > >  * In practice, clients do not accept a version mismatch
> and
> > >  * will abort the handshake with an error.
> > >  */
> > > if (i == 1 && s->version == s->session->ssl_version) { /*
> > previous
> > > *
> > session */
> > > s->hit = 1;
> > > } else if (i == -1)
> > > goto err;
> > > else {  /* i == 0 */
> > >
> > > if (!ssl_get_new_session(s, 1))
> > > goto err;
> > > }
> > >
> > > Since s->version is with 0xFEFD and s->session->ssl_version is
> 0xFEFF,
> > > we always try for new session and wont land on to session
> resumption
> > > though client has sent the  session_id.
> > >
> > > Is this intended behaviour? Please clarify.
> >
> >
> > No. This appears to be a bug introduced by commit 03d14f588734 in
> > November 2014.
> >
> > The real problem though is that the DTLS version negotiation is
> > happening too late - after session resumption. Interestingly this
> only
> > seems to be a problem in 1.0.2. In 1.1.0 this is working correctly
> (the
> > version negotiation logic has been substantially rewritten in the new
> > version).
> >
> > Please could you try out the attached patch? Let me know how you get
> on.
> >
> > Thanks
> >
> > Matt
> >
> > --
> > openssl-dev mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> >
> >
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Matt Caswell]

On 13/05/16 18:33, Rajeswari K wrote:
> Hi Matt,
> 
> Thanks for the response. 
> 
> But, this fix doesn't perform session resumption. 

Did you try the patch?

As you pointed out we hit the following line:

if (i == 1 && s->version == s->session->ssl_version) { /* previous
* session */

The version from the SSL object and the version from the session do not
match and that is why session resumption does not take place.

The reason that the versions do not match is because version negotiation
takes place *after* this check. So at this point s->version equals
DTLS_ANY_VERSION. My patch moves the version negotiation to before the
above test so that s->version should now be equal to DTLSv1, and
therefore should be the same as in s->session->ssl_version, and session
resumption should be successful.

Matt



> 
> Thanks,
> Rajeswari.
> 
> On Wed, May 11, 2016 at 2:56 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 10/05/16 18:34, Rajeswari K wrote:
> > Hello openssl-dev team,
> >
> > Having query regarding DTLS session resumption when configured SSL_CTX
> > with DTLS_ANY_VERSION.
> >
> > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> >
> > During handshake, we landed on to version DTLS1.0.i.e.
> > s->session->version holds 0xFEFF.
> >
> > In order to perform session resumption, we derived new SSL structure
> > from global ssl_ctx using SSL_new() and tried performing ssl
> handshake.
> >
> > With the below logic,
> > else {
> > i = ssl_get_prev_session(s, p, j, d + n);
> > /*
> >  * Only resume if the session's version matches the negotiated
> >  * version.
> >  * RFC 5246 does not provide much useful advice on resumption
> >  * with a different protocol version. It doesn't forbid it but
> >  * the sanity of such behaviour would be questionable.
> >  * In practice, clients do not accept a version mismatch and
> >  * will abort the handshake with an error.
> >  */
> > if (i == 1 && s->version == s->session->ssl_version) { /*
> previous
> > *
> session */
> > s->hit = 1;
> > } else if (i == -1)
> > goto err;
> > else {  /* i == 0 */
> >
> > if (!ssl_get_new_session(s, 1))
> > goto err;
> > }
> >
> > Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
> > we always try for new session and wont land on to session resumption
> > though client has sent the  session_id.
> >
> > Is this intended behaviour? Please clarify.
> 
> 
> No. This appears to be a bug introduced by commit 03d14f588734 in
> November 2014.
> 
> The real problem though is that the DTLS version negotiation is
> happening too late - after session resumption. Interestingly this only
> seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
> version negotiation logic has been substantially rewritten in the new
> version).
> 
> Please could you try out the attached patch? Let me know how you get on.
> 
> Thanks
> 
> Matt
> 
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> 
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Rajeswari K]

Hi Matt,

Thanks for the response.

But, this fix doesn't perform session resumption.

Thanks,
Rajeswari.

On Wed, May 11, 2016 at 2:56 PM, Matt Caswell  wrote:

>
>
> On 10/05/16 18:34, Rajeswari K wrote:
> > Hello openssl-dev team,
> >
> > Having query regarding DTLS session resumption when configured SSL_CTX
> > with DTLS_ANY_VERSION.
> >
> > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> > support both the versions (i.e. DTLS1.0 and DTLS1.2).
> >
> > During handshake, we landed on to version DTLS1.0.i.e.
> > s->session->version holds 0xFEFF.
> >
> > In order to perform session resumption, we derived new SSL structure
> > from global ssl_ctx using SSL_new() and tried performing ssl handshake.
> >
> > With the below logic,
> > else {
> > i = ssl_get_prev_session(s, p, j, d + n);
> > /*
> >  * Only resume if the session's version matches the negotiated
> >  * version.
> >  * RFC 5246 does not provide much useful advice on resumption
> >  * with a different protocol version. It doesn't forbid it but
> >  * the sanity of such behaviour would be questionable.
> >  * In practice, clients do not accept a version mismatch and
> >  * will abort the handshake with an error.
> >  */
> > if (i == 1 && s->version == s->session->ssl_version) { /*
> previous
> > *
> session */
> > s->hit = 1;
> > } else if (i == -1)
> > goto err;
> > else {  /* i == 0 */
> >
> > if (!ssl_get_new_session(s, 1))
> > goto err;
> > }
> >
> > Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
> > we always try for new session and wont land on to session resumption
> > though client has sent the  session_id.
> >
> > Is this intended behaviour? Please clarify.
>
>
> No. This appears to be a bug introduced by commit 03d14f588734 in
> November 2014.
>
> The real problem though is that the DTLS version negotiation is
> happening too late - after session resumption. Interestingly this only
> seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
> version negotiation logic has been substantially rewritten in the new
> version).
>
> Please could you try out the attached patch? Let me know how you get on.
>
> Thanks
>
> Matt
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Matt Caswell]

On 10/05/16 18:34, Rajeswari K wrote:
> Hello openssl-dev team,
> 
> Having query regarding DTLS session resumption when configured SSL_CTX
> with DTLS_ANY_VERSION. 
> 
> When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
> DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
> support both the versions (i.e. DTLS1.0 and DTLS1.2).
> 
> During handshake, we landed on to version DTLS1.0.i.e.
> s->session->version holds 0xFEFF. 
> 
> In order to perform session resumption, we derived new SSL structure
> from global ssl_ctx using SSL_new() and tried performing ssl handshake.
> 
> With the below logic, 
> else {
> i = ssl_get_prev_session(s, p, j, d + n);
> /*
>  * Only resume if the session's version matches the negotiated
>  * version.
>  * RFC 5246 does not provide much useful advice on resumption
>  * with a different protocol version. It doesn't forbid it but
>  * the sanity of such behaviour would be questionable.
>  * In practice, clients do not accept a version mismatch and
>  * will abort the handshake with an error.
>  */
> if (i == 1 && s->version == s->session->ssl_version) { /* previous
> * session */
> s->hit = 1;
> } else if (i == -1)
> goto err;
> else {  /* i == 0 */
> 
> if (!ssl_get_new_session(s, 1))
> goto err;
> }
> 
> Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
> we always try for new session and wont land on to session resumption
> though client has sent the  session_id. 
> 
> Is this intended behaviour? Please clarify.


No. This appears to be a bug introduced by commit 03d14f588734 in
November 2014.

The real problem though is that the DTLS version negotiation is
happening too late - after session resumption. Interestingly this only
seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
version negotiation logic has been substantially rewritten in the new
version).

Please could you try out the attached patch? Let me know how you get on.

Thanks

Matt
From f835f1ecbb3aa9766ee647f4b7e042e325bacfc6 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Wed, 11 May 2016 10:12:09 +0100
Subject: [PATCH] In Server-side DTLS negotiate the version before session
 resumption

This commit moves the server side DTLS version negotiation to before
session resumption is done. This is so that during the resumption we can
properly check that the negotiated version matches the session we are
trying to resume. This fixes a bug where a DTLSv1.2 capable server is
unable to resume sessions with DTLSv1.0 clients.
---
 ssl/s3_srvr.c | 50 +-
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/ssl/s3_srvr.c b/ssl/s3_srvr.c
index ab28702..20997c6 100644
--- a/ssl/s3_srvr.c
+++ b/ssl/s3_srvr.c
@@ -1010,6 +1010,31 @@ int ssl3_get_client_hello(SSL *s)
 goto f_err;
 }
 
+if (SSL_IS_DTLS(s) && s->method->version == DTLS_ANY_VERSION) {
+/* Select version to use */
+if (s->client_version <= DTLS1_2_VERSION &&
+!(s->options & SSL_OP_NO_DTLSv1_2)) {
+s->version = DTLS1_2_VERSION;
+s->method = DTLSv1_2_server_method();
+} else if (tls1_suiteb(s)) {
+SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,
+   SSL_R_ONLY_DTLS_1_2_ALLOWED_IN_SUITEB_MODE);
+s->version = s->client_version;
+al = SSL_AD_PROTOCOL_VERSION;
+goto f_err;
+} else if (s->client_version <= DTLS1_VERSION &&
+   !(s->options & SSL_OP_NO_DTLSv1)) {
+s->version = DTLS1_VERSION;
+s->method = DTLSv1_server_method();
+} else {
+SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,
+   SSL_R_WRONG_VERSION_NUMBER);
+s->version = s->client_version;
+al = SSL_AD_PROTOCOL_VERSION;
+goto f_err;
+}
+}
+
 s->hit = 0;
 /*
  * Versions before 0.9.7 always allow clients to resume sessions in
@@ -1104,31 +1129,6 @@ int ssl3_get_client_hello(SSL *s)
 }
 
 p += cookie_len;
-if (s->method->version == DTLS_ANY_VERSION) {
-/* Select version to use */
-if (s->client_version <= DTLS1_2_VERSION &&
-!(s->options & SSL_OP_NO_DTLSv1_2)) {
-s->version = DTLS1_2_VERSION;
-s->method = DTLSv1_2_server_method();
-} else if (tls1_suiteb(s)) {
-SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,
-   SSL_R_ONLY_DTLS_1_2_ALLOWED_IN_SUITEB_MODE);
-s->version = s->client_version;
-al = SSL_AD_PROTOCOL_VERSION;
-goto f_err;
-} else if (s->client_version <= DTLS1_VERSION &&
-  

[openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Rajeswari K]

Hello openssl-dev team,

Having query regarding DTLS session resumption when configured SSL_CTX with
DTLS_ANY_VERSION.

When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to support
both the versions (i.e. DTLS1.0 and DTLS1.2).

During handshake, we landed on to version DTLS1.0.i.e. s->session->version
holds 0xFEFF.

In order to perform session resumption, we derived new SSL structure from
global ssl_ctx using SSL_new() and tried performing ssl handshake.

With the below logic,
else {
i = ssl_get_prev_session(s, p, j, d + n);
/*
 * Only resume if the session's version matches the negotiated
 * version.
 * RFC 5246 does not provide much useful advice on resumption
 * with a different protocol version. It doesn't forbid it but
 * the sanity of such behaviour would be questionable.
 * In practice, clients do not accept a version mismatch and
 * will abort the handshake with an error.
 */
if (i == 1 && s->version == s->session->ssl_version) { /* previous
* session */
s->hit = 1;
} else if (i == -1)
goto err;
else {  /* i == 0 */

if (!ssl_get_new_session(s, 1))
goto err;
}

Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF, we
always try for new session and wont land on to session resumption though
client has sent the  session_id.

Is this intended behaviour? Please clarify.

Thanks,
Rajeswari.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3695] DTLS Handshake issue (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash

[sanchit arora via RT]

Bug report

OS: Red hat enterprise Linux 6.5

OpenSSL Version: 1.0.1e-30

While doing DTLS testing with openssl-1.0.1e-30 Version and patches
for RT3327, RT3470 and RT3483 on top of that, we are facing an issue
where our process is crashing during the duration run of 24 hours.

Use Case:
*There are 125 DTLS Server Connections and 125 DTLS Client Connections.
*Connection Attempts towards Server connections are also being
made every 1 second.
*Client Connections are initiating connection attempts every 1 second .
*SSL Handshake is made to fail so that connection attempts
continues and there are no crashes observed.

During the above duration run, process is always crashing at the below
location always.

#4  signal handler called
#5  0x7f61e97188e9 in sha1_block_data_order_ssse3 () from
/usr/lib64/libcrypto.so.10
#6  0xad89a0d6776026f6 in ?? ()
#7  0xf9e71fd74025dad7 in ?? ()
#8  0x2243d5d8167d7997 in ?? ()
#9  0x8bbb75d9b4efd5d8 in ?? ()
#10 0xea9689da4d4ac2cb in ?? ()
#11 0x7067bc5f5034983b in ?? ()
#12 0xe19f5aa4a5679ed0 in ?? ()
#13 0x8ecbf7e83d1d8ccd in ?? ()
#14 0x7f61e9a827ce in state () from /usr/lib64/libcrypto.so.10
#15 0xbc803cd0 in ?? ()
#16 0x0011 in ?? ()
#17 0x7f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10
#18 0x7f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10
#19 0x7f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10

When we tested with openssl-1.0.1e-16 Version and patches for RT3327,
RT3470 and RT3483 on top of that, the use case works fine.

On investigation, we found that there are 11 patches added between
openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following
3 patches are related to DTLS.

openssl-1.0.1e-dtls-ecc-ext.
patch
openssl-1.0.1e-cve-2014-3513.
patch
openssl-1.0.1e-fallback-scsv.patch

We have narrowed down that when we use openssl-1.0.1e-30 Version with
the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470
and RT3483 on top of that, process crashes with the above abterm
during the duration run of 24 hours.

When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from
openssl-1.0.1e-30 Version, we didn't see an abterm during the duration
run of 24  hours.

Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is
causing the abterm in the duration run.

Please let us know if there could be issues with the
openssl-1.0.1e-dtls-ecc-ext.patch?

Patch Details:

https://bugzilla.redhat.com/show_bug.cgi?id=1119800


Regards,
Sanchit Arora


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3695] DTLS Handshake issue (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash

[Salz, Rich]

Matt tried to explain this before.

1.0.1e-30 is not a version that OpenSSL provides.  You will have to contact 
your vendor.

The backtrace information is not usable as there are no function names; you 
will have to build a debugging version.

We cannot help you.
--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3695] DTLS Handshake issue (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash

[Salz, Rich via RT]

Matt tried to explain this before.

1.0.1e-30 is not a version that OpenSSL provides.  You will have to contact 
your vendor.

The backtrace information is not usable as there are no function names; you 
will have to build a debugging version.

We cannot help you.
--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Matt Caswell via RT]

On Thu Jan 15 17:21:35 2015, matt wrote:
 In response to your previous documentation question it is
 (unfortunately)
 undocumented. :-(
 The best I can offer you is the source code:
 int read_ahead; /* Read as many input bytes as possible * (for non-
 blocking
 reads) */
 With regards to your second point, I consider it a bug that this is
 not the
 default for DTLS. Unfortunately that bug has remained dormant until
 the fix for
 CVE-2014-0206 exposed it.

 I'm keeping this ticket open, until we have a proper fix. For now
 though the
 workaround is to use the SSL_CTX_set_read_ahead function directly.

A slight correction to the notes above. The reference should be to
CVE-2014-3571 (not CVE-2014-0206 as stated).

I have now committed the fix for this problem. See commit 8dd4ad0ff in master
(for 1.0.1 see 1895583). This fix makes read_ahead the default for DTLS...and
in fact you can't turn it off now for DTLS either (calls to the read_ahead
functions are ignored).

I've also added some documentation for the read_ahead functions in commit
85074745. These are now irrelevant for DTLS (since you can't turn read_ahead
off), but still relevant for TLS.

Closing this ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Matt Caswell via RT]

On Thu Jan 15 17:01:51 2015, shir...@gmail.com wrote:
 Hi all,

 Also, just for completeness, I want to point out I'm a fortunate case
 where I can actually touch the code and recompile it to fix the
 issue. I'm sure that other cases are not so fortunate. IMHO, when
 DTLS method is used, that call should be made by default in the
 internals of OpenSSL

In response to your previous documentation question it is (unfortunately)
undocumented. :-(
The best I can offer you is the source code:
int read_ahead; /* Read as many input bytes as possible * (for non-blocking
reads) */
With regards to your second point, I consider it a bug that this is not the
default for DTLS. Unfortunately that bug has remained dormant until the fix for
CVE-2014-0206 exposed it.

I'm keeping this ticket open, until we have a proper fix. For now though the
workaround is to use the SSL_CTX_set_read_ahead function directly.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Matt,

Thank you for the support. This was lucrative and good response time!

Best regards,
Andrei

 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

Matt,

Thank you for the support. This was lucrative and good response time!

Best regards,
Andrei

 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

Hi,

Adding SSL_CTX_set_read_ahead(pSslContext, 1); fixed both the test app and 
the real app I'm working on.

May I ask where should I read more about this function? I'm grateful that it 
now works, but is kind of a tough thing to just swallow this info without 
chewing on it a bit :)

Best regards,
Andrei

 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Hi,

Adding SSL_CTX_set_read_ahead(pSslContext, 1); fixed both the test app and 
the real app I'm working on.

May I ask where should I read more about this function? I'm grateful that it 
now works, but is kind of a tough thing to just swallow this info without 
chewing on it a bit :)

Best regards,
Andrei

 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Hi all,

Also, just for completeness, I want to point out I'm a fortunate case where I 
can actually touch the code and recompile it to fix the issue. I'm sure that 
other cases are not so fortunate. IMHO, when DTLS method is used, that call 
should be made by default in the internals of OpenSSL

Best regards,
Andrei

 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

Hi all,

Also, just for completeness, I want to point out I'm a fortunate case where I 
can actually touch the code and recompile it to fix the issue. I'm sure that 
other cases are not so fortunate. IMHO, when DTLS method is used, that call 
should be made by default in the internals of OpenSSL

Best regards,
Andrei

 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Matt Caswell via RT]

Please could you try making the following call:

SSL_CTX_set_read_ahead(ctx, 1);

Insert it immediately after these lines in your test code:
pSslContext = SSL_CTX_new(DTLSv1_server_method()); assert(pSslContext != NULL);
assert(SSL_CTX_use_certificate(pSslContext, pX509) == 1);
assert(SSL_CTX_use_PrivateKey(pSslContext, pX509Key) == 1);
assert(SSL_CTX_check_private_key(pSslContext) == 1);
Thanks

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Matt Caswell via RT]

On Wed Jan 14 21:21:46 2015, shir...@gmail.com wrote:
 Hi all,

 I believe I have found a bug which is only present in the latest
 versions (1.0.1k)

 I have created a simple C test which does the following things in this
 order:

 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept

 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent
 over the wire

 Observed:
 The output BIO is empty, the handshake never succeeds

 Same file test app linked with OpenSSL 1.0.1j works as expected, the
 output is generated.


Not sure what I'm supposed to be seeing here? I get the same result with both
1.01j and 1.0.1k...no errors reported.

What platform are you on?

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

Forgot to add the 1.0.1k version info:
$ /tmp/ssl/bin/openssl version
OpenSSL 1.0.1k 8 Jan 2015

 On Jan 14, 2015, at 22:54, Eugen-Andrei Gavriloaie shir...@gmail.com wrote:
 
 Hi Matt,
 
 Here are more explanations:
 
 On my Mac OS X Yosemite, the OS provided OpenSSL version
 $ openssl version
 OpenSSL 1.0.1j 15 Oct 2014
 
 Compiling the test
 $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto 
 -o /tmp/dtls_bug
 
 Running the test
 $ /tmp/dtls_bug 
 $ 
 
 As we can see, everything looks good, nothing happens, the app exist with 0 
 error code
 
 On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it 
 into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling:
 $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a 
 /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug
 
 Running:
 $ /tmp/dtls_bug 
 Assertion failed: (pSSLBuffer-length != 0), function main, file 
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
 Abort trap: 6
 
 As we can see, it fails that that line where I expect the output buffer to be 
 populated with an answer and is not happening. The pSSLBuffer-length != 0 
 fails
 
 Same behavior can be seen on Ubuntu 14.10 64 bit
 
 Best regards,
 Andrei
 
 
 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
 


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Bug report: OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Sorry for the mistake. here is the attachment again
/*
 *  Created by Gavriloaie Eugen-Andrei (shir...@gmail.com)
 *
 * The logical steps:
 * 1. initialize the SSL library
 * 2. creates an X509 key and cert
 * 3. creates an DTLS server SSL context
 * 4. Setup 2 memory BIO instances on the SSL context
 * 5. Feed the input BIO with a hardcoded Client Hello packet
 * 6. Call SSL_accept
 *
 * Wanted:
 * The output BIO should contain a packet (Server Hello) to be sent over the 
wire
 *
 * Observed on OpenSSL 1.0.1k:
 * The output BIO is empty, the handshake never succeeds
 */

#include openssl/conf.h
#include openssl/x509.h
#include openssl/ssl.h
#include openssl/rand.h
#include openssl/err.h
#include openssl/engine.h
#include assert.h

#define X509_KEY_SIZE 1024

void InitSSL();
void CleanupSSL();
EVP_PKEY * CreateCertificateKey();
X509 * CreateCertificate(EVP_PKEY *pKey);

int main(void) {
//first, init the OpenSSL library
InitSSL();

//define a Client Hello
unsigned char buffer[] = {
0x16, 0xfe, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x6d, 0x01, 0x00, 0x00,
0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x61, 0xfe, 0xff, 0xa1, 0xe1, 0xcb, 0x7f, 0x76,
0xb9, 0x42, 0x7c, 0x97, 0xaa, 0x1e, 0x9f, 0x5e,
0x18, 0x62, 0xe1, 0xe0, 0x29, 0x7b, 0xdc, 0xf3,
0x57, 0x02, 0x89, 0xab, 0x82, 0x80, 0x91, 0x63,
0x33, 0x98, 0xce, 0x00, 0x00, 0x00, 0x18, 0xc0,
0x14, 0xc0, 0x0a, 0x00, 0x39, 0x00, 0x35, 0xc0,
0x19, 0xc0, 0x13, 0xc0, 0x09, 0x00, 0x33, 0x00,
0x2f, 0xc0, 0x18, 0x00, 0x0a, 0x00, 0xff, 0x01,
0x00, 0x00, 0x1f, 0x00, 0x23, 0x00, 0x00, 0x00,
0x0e, 0x00, 0x05, 0x00, 0x02, 0x00, 0x01, 0x00,
0x00, 0x0b, 0x00, 0x02, 0x01, 0x00, 0x00, 0x0a,
0x00, 0x08, 0x00, 0x06, 0x00, 0x17, 0x00, 0x18,
0x00, 0x19
};

X509 *pX509 = NULL;
EVP_PKEY *pX509Key = NULL;
SSL_CTX *pSslContext = NULL;
SSL *pSSL = NULL;
BIO *pNetToSSLBIO = NULL;
BIO *pSSLToNetBIO = NULL;
BUF_MEM *pSSLBuffer = NULL;

//initialize the X509 key and cert
pX509Key = CreateCertificateKey();
assert(pX509Key != NULL);
pX509 = CreateCertificate(pX509Key);
assert(pX509 != NULL);

//create a SSL context blueprint and setup the X509 key and cert into it
pSslContext = SSL_CTX_new(DTLSv1_server_method());
assert(pSslContext != NULL);
assert(SSL_CTX_use_certificate(pSslContext, pX509) == 1);
assert(SSL_CTX_use_PrivateKey(pSslContext, pX509Key) == 1);
assert(SSL_CTX_check_private_key(pSslContext) == 1);

//create a SSL context using the blueprints above
pSSL = SSL_new(pSslContext);
assert(pSSL != NULL);

//create 2 memory BIO to simulate the I/O

//used to feed data FROM network TO SSL
pNetToSSLBIO = BIO_new(BIO_s_mem());
assert(pNetToSSLBIO != NULL);

//used by SSL context to store data that needs to be eventually sent 
out to the network
pSSLToNetBIO = BIO_new(BIO_s_mem());
assert(pSSLToNetBIO != NULL);

//set the BIOs into the SSL context
SSL_set_bio(pSSL, pNetToSSLBIO, pSSLToNetBIO);

//simulate network input by appending the data to the input BIO
assert(BIO_write(pNetToSSLBIO, buffer, sizeof (buffer)) == sizeof 
(buffer));
BIO_get_mem_ptr(pNetToSSLBIO, pSSLBuffer);
assert((pSSLBuffer != NULL)(pSSLBuffer-length == sizeof (buffer)));

//call SSL_accept
BIO_get_mem_ptr(pSSLToNetBIO, pSSLBuffer);
assert(pSSLBuffer != NULL);
assert(pSSLBuffer-length == 0);
SSL_accept(pSSL);

//the output BIO MUST contain some data at this point
BIO_get_mem_ptr(pSSLToNetBIO, pSSLBuffer);
assert(pSSLBuffer != NULL);
assert(pSSLBuffer-length != 0);

//cleanup
SSL_free(pSSL);
SSL_CTX_free(pSslContext);
X509_free(pX509);
EVP_PKEY_free(pX509Key);
CleanupSSL();

return 0;
}

void InitSSL() {
//init the random numbers generator
int length = 16;
int *pBuffer = (int *) malloc(length * sizeof (int));
while (RAND_status() == 0) {
for (int i = 0; i  length; i++) {
pBuffer[i] = rand();
}

RAND_seed(pBuffer, length * sizeof (int));
}
free(pBuffer);

//init the SSL library
SSL_library_init();

//load SSL resources
SSL_load_error_strings();
ERR_load_SSL_strings();
ERR_load_CRYPTO_strings();
ERR_load_crypto_strings();
OpenSSL_add_all_algorithms();
OpenSSL_add_all_ciphers();
OpenSSL_add_all_digests();
}

void 

[openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

Hi all,

I believe I have found a bug which is only present in the latest versions 
(1.0.1k)

I have created a simple C test which does the following things in this order:

1. initialize the SSL library
2. creates an X509 key and cert
3. creates an DTLS server SSL context
4. Setup 2 memory BIO instances on the SSL context
5. Feed the input BIO with a hardcoded Client Hello packet
6. Call SSL_accept

Wanted:
The output BIO should contain a packet (Server Hello) to be sent over the wire

Observed:
The output BIO is empty, the handshake never succeeds

Same file test app linked with OpenSSL 1.0.1j works as expected, the output is 
generated.

I have attached the C file.

Best regards,
Andrei




dtls_bug.c
Description: Binary data



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

Hi Matt,

Here are more explanations:

On my Mac OS X Yosemite, the OS provided OpenSSL version
$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

Compiling the test
$ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto 
-o /tmp/dtls_bug

Running the test
$ /tmp/dtls_bug 
$ 

As we can see, everything looks good, nothing happens, the app exist with 0 
error code

On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into 
/tmp/ssl as a static lib (with shared lib behaves the same) Compiling:
$ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a 
/tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug

Running:
$ /tmp/dtls_bug 
Assertion failed: (pSSLBuffer-length != 0), function main, file 
/Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
Abort trap: 6

As we can see, it fails that that line where I expect the output buffer to be 
populated with an answer and is not happening. The pSSLBuffer-length != 0 fails

Same behavior can be seen on Ubuntu 14.10 64 bit

Best regards,
Andrei


 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

And from an Ubuntu box (apparently, it runs 1.0.1f)

shiretu@ubuntu:/tmp$ gcc -std=c99 dtls_bug.c -lssl -lcrypto -o dtls_bug

shiretu@ubuntu:/tmp$ ./dtls_bug 
dtls_bug: dtls_bug.c:110: main: Assertion `pSSLBuffer-length != 0' failed.
Aborted (core dumped)

shiretu@ubuntu:/tmp$ uname -a
Linux ubuntu 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:56:17 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux

shiretu@ubuntu:/tmp$ openssl version
OpenSSL 1.0.1f 6 Jan 2014

shiretu@ubuntu:/tmp$ ldd dtls_bug
linux-vdso.so.1 =  (0x7fff0fbe7000)
libssl.so.1.0.0 = /lib/x86_64-linux-gnu/libssl.so.1.0.0 
(0x7fec11f22000)
libcrypto.so.1.0.0 = /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
(0x7fec11b3f000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fec11779000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fec11575000)
/lib64/ld-linux-x86-64.so.2 (0x7fec12189000)



 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Viktor Dukhovni]

On Wed, Jan 14, 2015 at 10:54:57PM +0200, Eugen-Andrei Gavriloaie wrote:

 On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it 
 into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling:

 $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a 
 /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug

This picks up libraries from 1.0.1k and headers from some other
release.  Try with -I/tmp/ssl/include or similar making sure the
right headers are used.  You should not need -Wno-deprecated-declarations,
that should only be needed to silence consequences of including
Apple's headers.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Matt Caswell via RT]

On Wed Jan 14 21:55:17 2015, shir...@gmail.com wrote:
 Hi Matt,

 Here are more explanations:

 On my Mac OS X Yosemite, the OS provided OpenSSL version
 $ openssl version
 OpenSSL 1.0.1j 15 Oct 2014

 Compiling the test
 $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl
 -lcrypto -o /tmp/dtls_bug

 Running the test
 $ /tmp/dtls_bug
 $

 As we can see, everything looks good, nothing happens, the app exist
 with 0 error code

 On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and
 installed it into /tmp/ssl as a static lib (with shared lib behaves
 the same) Compiling:
 $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a
 /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug

 Running:
 $ /tmp/dtls_bug
 Assertion failed: (pSSLBuffer-length != 0), function main, file
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
 Abort trap: 6

 As we can see, it fails that that line where I expect the output
 buffer to be populated with an answer and is not happening. The
 pSSLBuffer-length != 0 fails

 Same behavior can be seen on Ubuntu 14.10 64 bit

Does it work in s_client/s_server? i.e.

Start an s_server (you'll need an appropriate cert/key):
openssl s_server -dtls1

Start an s_client:
openssl s_client -dtls1

They should complete a handshake successfully.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

And from an Ubuntu box (apparently, it runs 1.0.1f)

shiretu@ubuntu:/tmp$ gcc -std=c99 dtls_bug.c -lssl -lcrypto -o dtls_bug

shiretu@ubuntu:/tmp$ ./dtls_bug 
dtls_bug: dtls_bug.c:110: main: Assertion `pSSLBuffer-length != 0' failed.
Aborted (core dumped)

shiretu@ubuntu:/tmp$ uname -a
Linux ubuntu 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:56:17 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux

shiretu@ubuntu:/tmp$ openssl version
OpenSSL 1.0.1f 6 Jan 2014

shiretu@ubuntu:/tmp$ ldd dtls_bug
linux-vdso.so.1 =  (0x7fff0fbe7000)
libssl.so.1.0.0 = /lib/x86_64-linux-gnu/libssl.so.1.0.0 
(0x7fec11f22000)
libcrypto.so.1.0.0 = /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
(0x7fec11b3f000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fec11779000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fec11575000)
/lib64/ld-linux-x86-64.so.2 (0x7fec12189000)



 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Forgot to add the 1.0.1k version info:
$ /tmp/ssl/bin/openssl version
OpenSSL 1.0.1k 8 Jan 2015

 On Jan 14, 2015, at 22:54, Eugen-Andrei Gavriloaie shir...@gmail.com wrote:
 
 Hi Matt,
 
 Here are more explanations:
 
 On my Mac OS X Yosemite, the OS provided OpenSSL version
 $ openssl version
 OpenSSL 1.0.1j 15 Oct 2014
 
 Compiling the test
 $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto 
 -o /tmp/dtls_bug
 
 Running the test
 $ /tmp/dtls_bug 
 $ 
 
 As we can see, everything looks good, nothing happens, the app exist with 0 
 error code
 
 On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it 
 into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling:
 $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a 
 /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug
 
 Running:
 $ /tmp/dtls_bug 
 Assertion failed: (pSSLBuffer-length != 0), function main, file 
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
 Abort trap: 6
 
 As we can see, it fails that that line where I expect the output buffer to be 
 populated with an answer and is not happening. The pSSLBuffer-length != 0 
 fails
 
 Same behavior can be seen on Ubuntu 14.10 64 bit
 
 Best regards,
 Andrei
 
 
 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
 

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Viktor Dukhovni]

On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote:

 Dynamic:
 $ ls -Al /tmp/ssl/lib/
 total 11336
 drwxr-xr-x  14 shiretu  wheel  476 Jan 14 23:27 engines
 -r-xr-xr-x   1 shiretu  wheel  1602352 Jan 14 23:27 libcrypto.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel  3196880 Jan 14 23:27 libcrypto.a
 lrwxr-xr-x   1 shiretu  wheel   21 Jan 14 23:27 libcrypto.dylib - 
 libcrypto.1.0.0.dylib
 -r-xr-xr-x   1 shiretu  wheel   382440 Jan 14 23:27 libssl.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel   605504 Jan 14 23:27 libssl.a
 lrwxr-xr-x   1 shiretu  wheel   18 Jan 14 23:27 libssl.dylib - 
 libssl.1.0.0.dylib
 drwxr-xr-x   5 shiretu  wheel  170 Jan 14 23:27 pkgconfig

And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)?
And /tmp/ssl/bin/openssl version -a output is what?

 $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl 
 -lcrypto -o /tmp/dtls_bug
 
 $ otool -L /tmp/dtls_bug 
 /tmp/dtls_bug:
   /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current 
 version 1.0.0)
   /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, 
 current version 1.0.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
 version 1213.0.0)

 $ /tmp/dtls_bug 
 Assertion failed: (pSSLBuffer-length != 0), function main, file 
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
 Abort trap: 6

You should also update your code to report error return values from
SSL_accept() and print the contents of error stack.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Bug report: OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Hi all,

I believe I have found a bug which is only present in the latest versions 
(1.0.1k). I ran this test on a linux 64 ubuntu 14.10 and mac os x yosemite

I have created a simple C test which does the following things in this order:

1. initialize the SSL library
2. creates an X509 key and cert
3. creates an DTLS server SSL context
4. Setup 2 memory BIO instances on the SSL context
5. Feed the input BIO with a hardcoded Client Hello packet
6. Call SSL_accept

Wanted:
The output BIO should contain a packet (Server Hello) to be sent over the wire

Observed:
The output BIO is empty, the handshake never succeeds

Same file test app linked with OpenSSL 1.0.1j works as expected, the output is 
generated.

I have attached the C file.

Best regards,
Andrei



dtls_bug.c
Description: Binary data


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Dynamic:
$ ls -Al /tmp/ssl/lib/
total 11336
drwxr-xr-x  14 shiretu  wheel  476 Jan 14 23:27 engines
-r-xr-xr-x   1 shiretu  wheel  1602352 Jan 14 23:27 libcrypto.1.0.0.dylib
-rw-r--r--   1 shiretu  wheel  3196880 Jan 14 23:27 libcrypto.a
lrwxr-xr-x   1 shiretu  wheel   21 Jan 14 23:27 libcrypto.dylib - 
libcrypto.1.0.0.dylib
-r-xr-xr-x   1 shiretu  wheel   382440 Jan 14 23:27 libssl.1.0.0.dylib
-rw-r--r--   1 shiretu  wheel   605504 Jan 14 23:27 libssl.a
lrwxr-xr-x   1 shiretu  wheel   18 Jan 14 23:27 libssl.dylib - 
libssl.1.0.0.dylib
drwxr-xr-x   5 shiretu  wheel  170 Jan 14 23:27 pkgconfig


$ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl 
-lcrypto -o /tmp/dtls_bug

$ otool -L /tmp/dtls_bug 
/tmp/dtls_bug:
/tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current 
version 1.0.0)
/tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, 
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)


$ /tmp/dtls_bug 
Assertion failed: (pSSLBuffer-length != 0), function main, file 
/Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
Abort trap: 6


Static:
$ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include /tmp/ssl/lib/libssl.a 
/tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug

$ otool -L /tmp/dtls_bug 
/tmp/dtls_bug:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)

$ /tmp/dtls_bug 
Assertion failed: (pSSLBuffer-length != 0), function main, file 
/Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
Abort trap: 6

$ uname -a
Darwin shiretu.local 14.1.0 Darwin Kernel Version 14.1.0: Sun Dec 28 21:20:58 
PST 2014; root:xnu-2782.10.72~3/RELEASE_X86_64 x86_64



 On Jan 14, 2015, at 23:00, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
 
 On Wed, Jan 14, 2015 at 10:54:57PM +0200, Eugen-Andrei Gavriloaie wrote:
 
 On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it 
 into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling:
 
 $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a 
 /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug
 
 This picks up libraries from 1.0.1k and headers from some other
 release.  Try with -I/tmp/ssl/include or similar making sure the
 right headers are used.  You should not need -Wno-deprecated-declarations,
 that should only be needed to silence consequences of including
 Apple's headers.
 
 -- 
   Viktor.
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Hi Matt,

Here are more explanations:

On my Mac OS X Yosemite, the OS provided OpenSSL version
$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

Compiling the test
$ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto 
-o /tmp/dtls_bug

Running the test
$ /tmp/dtls_bug 
$ 

As we can see, everything looks good, nothing happens, the app exist with 0 
error code

On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into 
/tmp/ssl as a static lib (with shared lib behaves the same) Compiling:
$ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a 
/tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug

Running:
$ /tmp/dtls_bug 
Assertion failed: (pSSLBuffer-length != 0), function main, file 
/Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
Abort trap: 6

As we can see, it fails that that line where I expect the output buffer to be 
populated with an answer and is not happening. The pSSLBuffer-length != 0 fails

Same behavior can be seen on Ubuntu 14.10 64 bit

Best regards,
Andrei


 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

 On Jan 14, 2015, at 23:39, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
 
 On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote:
 
 Dynamic:
 $ ls -Al /tmp/ssl/lib/
 total 11336
 drwxr-xr-x  14 shiretu  wheel  476 Jan 14 23:27 engines
 -r-xr-xr-x   1 shiretu  wheel  1602352 Jan 14 23:27 libcrypto.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel  3196880 Jan 14 23:27 libcrypto.a
 lrwxr-xr-x   1 shiretu  wheel   21 Jan 14 23:27 libcrypto.dylib - 
 libcrypto.1.0.0.dylib
 -r-xr-xr-x   1 shiretu  wheel   382440 Jan 14 23:27 libssl.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel   605504 Jan 14 23:27 libssl.a
 lrwxr-xr-x   1 shiretu  wheel   18 Jan 14 23:27 libssl.dylib - 
 libssl.1.0.0.dylib
 drwxr-xr-x   5 shiretu  wheel  170 Jan 14 23:27 pkgconfig
 
 And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)?
 And /tmp/ssl/bin/openssl version -a output is what?
 
 $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl 
 -lcrypto -o /tmp/dtls_bug
 
 $ otool -L /tmp/dtls_bug 
 /tmp/dtls_bug:
  /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current 
 version 1.0.0)
  /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, 
 current version 1.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
 version 1213.0.0)
 
 $ /tmp/dtls_bug 
 Assertion failed: (pSSLBuffer-length != 0), function main, file 
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
 Abort trap: 6
 
 You should also update your code to report error return values from
 SSL_accept() and print the contents of error stack.
$ /tmp/dtls_bug 
ret: -1
sslErrorCode: 2
Assertion failed: (pSSLBuffer-length != 0), function main, file 
/Users/shiretu/Dropbox/Public/dtls_bug.c, line 114.
Abort trap: 6

errorCode 2 means SSL_ERROR_WANT_READ, which is consistent with the rejection 
of the input packet.

And the updated source:
https://dl.dropboxusercontent.com/u/2918563/dtls_bug.c

 
 -- 
   Viktor.
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

Looks like dtls1_get_record is always returning -1
Still digging...



 On Jan 15, 2015, at 00:01, Eugen-Andrei Gavriloaie shir...@gmail.com wrote:
 
 
 On Jan 14, 2015, at 23:39, Viktor Dukhovni openssl-us...@dukhovni.org 
 wrote:
 
 On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote:
 
 Dynamic:
 $ ls -Al /tmp/ssl/lib/
 total 11336
 drwxr-xr-x  14 shiretu  wheel  476 Jan 14 23:27 engines
 -r-xr-xr-x   1 shiretu  wheel  1602352 Jan 14 23:27 libcrypto.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel  3196880 Jan 14 23:27 libcrypto.a
 lrwxr-xr-x   1 shiretu  wheel   21 Jan 14 23:27 libcrypto.dylib - 
 libcrypto.1.0.0.dylib
 -r-xr-xr-x   1 shiretu  wheel   382440 Jan 14 23:27 libssl.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel   605504 Jan 14 23:27 libssl.a
 lrwxr-xr-x   1 shiretu  wheel   18 Jan 14 23:27 libssl.dylib - 
 libssl.1.0.0.dylib
 drwxr-xr-x   5 shiretu  wheel  170 Jan 14 23:27 pkgconfig
 
 And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)?
 And /tmp/ssl/bin/openssl version -a output is what?
 
 $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl 
 -lcrypto -o /tmp/dtls_bug
 
 $ otool -L /tmp/dtls_bug 
 /tmp/dtls_bug:
 /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current 
 version 1.0.0)
 /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, 
 current version 1.0.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
 version 1213.0.0)
 
 $ /tmp/dtls_bug 
 Assertion failed: (pSSLBuffer-length != 0), function main, file 
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
 Abort trap: 6
 
 You should also update your code to report error return values from
 SSL_accept() and print the contents of error stack.
 $ /tmp/dtls_bug 
 ret: -1
 sslErrorCode: 2
 Assertion failed: (pSSLBuffer-length != 0), function main, file 
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 114.
 Abort trap: 6
 
 errorCode 2 means SSL_ERROR_WANT_READ, which is consistent with the rejection 
 of the input packet.
 
 And the updated source:
 https://dl.dropboxusercontent.com/u/2918563/dtls_bug.c
 
 
 -- 
  Viktor.
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
 

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

 On Jan 14, 2015, at 23:39, Viktor Dukhovni openssl-us...@dukhovni.org wrote:
 
 On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote:
 
 Dynamic:
 $ ls -Al /tmp/ssl/lib/
 total 11336
 drwxr-xr-x  14 shiretu  wheel  476 Jan 14 23:27 engines
 -r-xr-xr-x   1 shiretu  wheel  1602352 Jan 14 23:27 libcrypto.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel  3196880 Jan 14 23:27 libcrypto.a
 lrwxr-xr-x   1 shiretu  wheel   21 Jan 14 23:27 libcrypto.dylib - 
 libcrypto.1.0.0.dylib
 -r-xr-xr-x   1 shiretu  wheel   382440 Jan 14 23:27 libssl.1.0.0.dylib
 -rw-r--r--   1 shiretu  wheel   605504 Jan 14 23:27 libssl.a
 lrwxr-xr-x   1 shiretu  wheel   18 Jan 14 23:27 libssl.dylib - 
 libssl.1.0.0.dylib
 drwxr-xr-x   5 shiretu  wheel  170 Jan 14 23:27 pkgconfig
 
 And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)?
$ ls -Al /tmp/ssl/include/
total 0
drwxr-xr-x  77 shiretu  wheel  2618 Jan 14 23:27 openssl

 And /tmp/ssl/bin/openssl version -a output is what?
$ /tmp/ssl/bin/openssl version
OpenSSL 1.0.1k 8 Jan 2015

 
 $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl 
 -lcrypto -o /tmp/dtls_bug
 
 $ otool -L /tmp/dtls_bug 
 /tmp/dtls_bug:
  /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current 
 version 1.0.0)
  /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, 
 current version 1.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
 version 1213.0.0)
 
 $ /tmp/dtls_bug 
 Assertion failed: (pSSLBuffer-length != 0), function main, file 
 /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110.
 Abort trap: 6
 
 You should also update your code to report error return values from
 SSL_accept() and print the contents of error stack.
 
 -- 
   Viktor.
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie]

The openssl s_server/s_client -dtls1 works

I now suspect a special edge case of dtls1_get_record function. That buffer I'm 
feeding into OpenSSL is taken from Chrome WebRTC DTLS handshake, and as we saw, 
is perfectly valid in older OpenSSL versions.

Still digging...
 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works

[Eugen-Andrei Gavriloaie via RT]

The openssl s_server/s_client -dtls1 works

I now suspect a special edge case of dtls1_get_record function. That buffer I'm 
feeding into OpenSSL is taken from Chrome WebRTC DTLS handshake, and as we saw, 
is perfectly valid in older OpenSSL versions.

Still digging...
 On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT r...@openssl.org 
 wrote:
 
 Hi all,
 
 I believe I have found a bug which is only present in the latest versions 
 (1.0.1k)
 
 I have created a simple C test which does the following things in this order:
 
 1. initialize the SSL library
 2. creates an X509 key and cert
 3. creates an DTLS server SSL context
 4. Setup 2 memory BIO instances on the SSL context
 5. Feed the input BIO with a hardcoded Client Hello packet
 6. Call SSL_accept
 
 Wanted:
 The output BIO should contain a packet (Server Hello) to be sent over the 
 wire
 
 Observed:
 The output BIO is empty, the handshake never succeeds
 
 Same file test app linked with OpenSSL 1.0.1j works as expected, the output 
 is generated.
 
 I have attached the C file.
 
 Best regards,
 Andrei
 
 
 dtls_bug.c
 
 
 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Openssl 1.0.0e: dtls segmentation fault after set SSL_OP_NO_QUERY_MTU

[Huaqing Wang]

Hi,

I don't know if any other person met this issue.
I use openssl1.0.0e, and working on dtls, in client side,  if I
set SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(ss_ssl, 1500);
I met a segmentation fault on the client side, using gdb I saw the error
happens in:

memcpy()
dtls_do_write()
dtls_connect()


And if I remove  SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(ssl, 1500);

It worked well.

For the same program if I run in Openssl 0.9.8e, it worked well
with set SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(ss_ssl, 1500);

So I am thinking this may be a bug in Openssl 1.0.0e.

-- 
Thank you.
Best Regards,
Huaqing Wang

Re: Openssl 1.0.0e: dtls segmentation fault after set SSL_OP_NO_QUERY_MTU

[Michael Tüxen]

On Sep 21, 2011, at 9:40 PM, Huaqing Wang wrote:

 Hi, 
 
 I don't know if any other person met this issue.
 I use openssl1.0.0e, and working on dtls, in client side,  if I set 
 SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
 SSL_set_mtu(ss_ssl, 1500);
 I met a segmentation fault on the client side, using gdb I saw the error 
 happens in:
 
 memcpy()
 dtls_do_write()
 dtls_connect()
 
 
 And if I remove  SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
 SSL_set_mtu(ssl, 1500);
 
 It worked well.
 
 For the same program if I run in Openssl 0.9.8e, it worked well with set 
 SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
 SSL_set_mtu(ss_ssl, 1500);
 
 So I am thinking this may be a bug in Openssl 1.0.0e.
I think you are hitting a bug for which a fix has already been submitted by 
Robin to
the request tracker. See
http://rt.openssl.org/Ticket/Display.html?id=2602

Please let us know if this fixes your issue.

Best regards
Michael
 
 -- 
 Thank you.
 Best Regards,
 Huaqing Wang
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL v0.9.8: DTLS and multicasting - will it work?

[rz1a]

Hello openssl-dev,

  When I has asked about securing the UDP traffic - I was told to use
  DTLS in OpenSSL v0.9.8.
  The UDP traffic of mine is a multicasting stream actually.

  Are there any ways to secure the multicasting with DTLS?

  (I'm looking for UDP/multicast support in the stunnel)
  
-- 
Best regards,
 Tony

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL and DTLS

[Eduardo Pérez]

On 2005-03-04 07:05:01 -0800, Prashant Kumar wrote:
 Does OpenSSL has plans to support DTLS ? Is there any good open source 
 prototype implementation?
In:
http://www.sipfoundry.org/reSIProcate/
there's the DTLS implementation:
http://scm.sipfoundry.org/viewsvn/resiprocate/main/sip/contrib/dtls/
of the DTLS spec authors.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

OpenSsl and DTLS

[Prashant Kumar]

Hello Group,

Does OpenSsl has plans to support DTLS ? Is there any good open source prototype implementation?

Regards,
Prashant kumar.
		Celebrate Yahoo!'s 10th Birthday!  
Yahoo! Netrospective: 100 Moments of the Web