Re: [openssl.org #1703] Bug report for DTLS

2008-11-24 Thread David Woodhouse 
Apologies for delayed response. There was some bureaucracy to go through
to make sure I had management approval for releasing the code which
explains my interest in the subject.

That's done now; we have a full open source client for the VPN in
question, and OpenSSL client support for BAD_DTLS_VER is the last piece
in the jigsaw for me.

http://git.infradead.org/users/dwmw2/openconnect.git
git://git.infradead.org/users/dwmw2/openconnect.git

On Wed, 2008-10-15 at 09:13 +0200, Andy Polyakov wrote:
  Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
  is not present in HEAD (0.9.9).
  
  That makes sense.
 
  I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
  pre-RFC version of DTLS was considered to be an OpenSSL-specific thing
  that would quickly die out as people upgraded to 0.9.8f and beyond?
 
 Right.
 
  Now we've observed that there are servers in the wild which implement
  that old OpenSSL-specific version of the protocol, but which we'd like
  to be compatible with.
 
 Could you clarify? Haven't you mentioned that it's about Cisco 
 AnyConnect VPN? Isn't it OpenSSL-based? If it's pre-0.9.8f-based, then 
 shouldn't you question if it's appropriate to use it at all because of 
 security problems?

They do update to a new version of OpenSSL periodically, and they also
backport security patches even more frequently than that, allegedly.

But their products use the pre-RFC version of DTLS, so they have to
remain compatible with that. So even though they're currently on 0.9.8f,
they're still using DTLS1_BAD_VER.

Their server _does_ seem to accept some variant of the _real_ DTLS
protocol, but it's strangely broken -- you have to calculate the MAC as
if the version number in the packets was DTLS1_BAD_VER, even though it
isn't. And although the _handshake_ works that way, the server still
seems to ignore all incoming data packets.

I strongly suspect that their implementation of REAL_VER is completely
broken, and that there is _no_ way to interoperate with it. The real
clients use DTLS1_BAD_VER, and that's what we need to use too.

  And if it turns out that their REAL_VER is not RFC-compliant, then
 why did they choose REAL_VER and not VENDOR_VER? 

They don't care about REAL_VER and probably aren't even aware that their
server seems to accept it. They never use it, and it's not tested. If
they do ever realise, they'll probably turn it off.

 In other words, can you remind the reason for re-introducing
 BAD_DTLS:-)

_My_ reason for wanting to re-introduce DTLS1_BAD_VER is purely
interoperability. There are servers out there which use it, which we
really really want to talk to. And it's a fairly simple patch.

 Even in worst case is DTLS the only option in 
 AnyConnect? I mean if it doesn't work, why not use TLS [till DTLS is 
 fixed to be RFC-compliant]?

This is a VPN, and TCP over TCP _really_ sucks.

The only viable option for connecting to these VPN servers is to use
DTLS1_BAD_VER, really.

  If I can actually get that working in HEAD, would
  a patch to support it be acceptable?

  I had a deeper look into the mailing list archive and I did not find
  any explicit statement on why this was handed differently in 0.9.8
  and in HEAD.
  Finally we would of course prefer to move people to update to an
  RFC compliant version, so I guess the pre-RFC support should be
  configurable somehow. Andy, what do you think?

With my patch, the pre-RFC support is only available if you manually set
up a session to be 'resumed' that way. We don't need anything more,
because the master-secret and session-id for the DTLS session are
actually exchanged over HTTPS in advance.

 My vote still goes for *not* implementing BAD_VER in HEAD.

Please reconsider.

Obviously the _correct_ thing for them to do is make REAL_VER work on
the server in parallel with BAD_VER, then slowly migrate their clients
to use REAL_VER and over time they can completely forget about BAD_VER.

But this is a vendor of proprietary software. Of _course_ they don't
have the wit to do that, and we have to interoperate with what we're
given.


-- 
dwmw2

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

Re: [openssl.org #1703] Bug report for DTLS

2008-10-15 Thread Andy Polyakov 

Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
is not present in HEAD (0.9.9).


That makes sense.

I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
pre-RFC version of DTLS was considered to be an OpenSSL-specific thing
that would quickly die out as people upgraded to 0.9.8f and beyond?


Right.


Now we've observed that there are servers in the wild which implement
that old OpenSSL-specific version of the protocol, but which we'd like
to be compatible with.


Could you clarify? Haven't you mentioned that it's about Cisco 
AnyConnect VPN? Isn't it OpenSSL-based? If it's pre-0.9.8f-based, then 
shouldn't you question if it's appropriate to use it at all because of 
security problems? If it's post-0.9.8f-based, what's the problem? 
Haven't you mentioned that it too accepts non-BAD_VER connections? If 
it's not 0.9.8f, then we have to assume they patch it themselves. 
Wouldn't it be reasonable to assume that their REAL_VER is 
RFC-compliant? If it doesn't inter-operate, wouldn't it be more 
appropriate to devote effort to figure out why? And if it turns out that 
their REAL_VER is not RFC-compliant, then why did they choose REAL_VER 
and not VENDOR_VER? In other words, can you remind the reason for 
re-introducing BAD_DTLS:-) Even in worst case is DTLS the only option in 
AnyConnect? I mean if it doesn't work, why not use TLS [till DTLS is 
fixed to be RFC-compliant]?



If I can actually get that working in HEAD, would
a patch to support it be acceptable?
  

I had a deeper look into the mailing list archive and I did not find
any explicit statement on why this was handed differently in 0.9.8
and in HEAD.
Finally we would of course prefer to move people to update to an
RFC compliant version, so I guess the pre-RFC support should be
configurable somehow. Andy, what do you think?


My vote still goes for *not* implementing BAD_VER in HEAD.

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

Re: [openssl.org #1703] Bug report for DTLS

2008-10-14 Thread Lutz Jaenicke 
David Woodhouse wrote:
 On Mon, 2008-10-13 at 09:01 +0200, Lutz Jaenicke via RT wrote:
   
 Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
 is not present in HEAD (0.9.9).
 

 That makes sense.

 I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
 pre-RFC version of DTLS was considered to be an OpenSSL-specific thing
 that would quickly die out as people upgraded to 0.9.8f and beyond?

 Now we've observed that there are servers in the wild which implement
 that old OpenSSL-specific version of the protocol, but which we'd like
 to be compatible with. If I can actually get that working in HEAD, would
 a patch to support it be acceptable?
   
I had a deeper look into the mailing list archive and I did not find
any explicit statement on why this was handed differently in 0.9.8
and in HEAD.
Finally we would of course prefer to move people to update to an
RFC compliant version, so I guess the pre-RFC support should be
configurable somehow. Andy, what do you think?

Best regards,
Lutz

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

[openssl.org #1703] Bug report for DTLS

2008-10-13 Thread Lutz Jaenicke via RT 
 [jaenicke - Fri Oct 10 12:42:51 2008]:
 
 I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I
 am not very familiar with the DTLS implementation so hopefully I did not
 break it.

Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
is not
present in HEAD (0.9.9).

Best regards,
Lutz

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

Re: [openssl.org #1703] Bug report for DTLS

2008-10-13 Thread David Woodhouse 
On Mon, 2008-10-13 at 09:01 +0200, Lutz Jaenicke via RT wrote:
 Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling
 is not present in HEAD (0.9.9).

That makes sense.

I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the
pre-RFC version of DTLS was considered to be an OpenSSL-specific thing
that would quickly die out as people upgraded to 0.9.8f and beyond?

Now we've observed that there are servers in the wild which implement
that old OpenSSL-specific version of the protocol, but which we'd like
to be compatible with. If I can actually get that working in HEAD, would
a patch to support it be acceptable?

-- 
dwmw2

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

Re: [openssl.org #1703] Bug report for DTLS

2008-10-10 Thread David Woodhouse via RT 
On Fri, 2008-10-10 at 12:42 +0200, Lutz Jaenicke via RT wrote:
 I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I
 am not very familiar with the DTLS implementation so hopefully I did not
 break it.

Thanks. Sorry to be impatient. I've got myself onto a team tasked with
implementing supporting for Linux connectivity to the company VPN, and
I'm very keep to avoid them settling on Cisco's client, which has some
fairly scary security holes as well as just integrating properly with
the desktop or being supportable, etc. 

I'm trying to present the open client which I've now written as a fait
accompili -- and aside from the OpenSSL part, I'm fairly much there. We
have packages for 'openconnect' and 'NetworkManager-openconnect' on the
way through the Fedora review process and we're about to get other
people to do the same for other distributions... all we need now is to
get the distributions' OpenSSL packages updated so that DTLS works and
we're not using TCP over TCP. And understandably, distributions want to
see the patches upstream before they ship them. Especially with one with
the extra option for Cisco compatibility.

-- 
dwmw2


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

[openssl.org #1703] Bug report for DTLS

2008-10-10 Thread Lutz Jaenicke via RT 
I have applied the patch to 0.9.8-stable and adopted it to 0.9.9-dev. I
am not very familiar with the DTLS implementation so hopefully I did not
break it.

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

[openssl.org #1703] Bug report for DTLS

2008-10-01 Thread David Woodhouse via RT 
I can reproduce this failure at will. All I need to do is set up a DTLS
connection, then somehow cause the write() call on the UDP socket to
return an error -- a firewall is an easy way of achieving that.

-- 
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED]  Intel Corporation


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

Re: [openssl.org #1703] Bug report for DTLS

2008-10-01 Thread David Woodhouse via RT 
On Thu, 2008-10-02 at 05:47 +0100, David Woodhouse wrote:
 I can reproduce this failure at will. All I need to do is set up a DTLS
 connection, then somehow cause the write() call on the UDP socket to
 return an error -- a firewall is an easy way of achieving that.

The whole _point_ of DTLS is that it's a datagram service. That
datagrams go missing. So buffering them up when we fail to send them --
even if we _weren't_ then going to crap ourselves and abort() as a
result -- was a bad idea in the first place.

(I include DTLS1_BAD_VER here because of RT#1751)

--- openssl-0.9.8g/ssl/s3_pkt.c~2006-11-29 14:45:14.0 +
+++ openssl-0.9.8g/ssl/s3_pkt.c 2008-10-02 06:41:07.0 +0100
@@ -753,8 +753,15 @@ int ssl3_write_pending(SSL *s, int type,
s-rwstate=SSL_NOTHING;
return(s-s3-wpend_ret);
}
-   else if (i = 0)
+   else if (i = 0) {
+   if (s-version == DTLS1_VERSION ||
+   s-version == DTLS1_BAD_VER) {
+   /* For DTLS, just drop it. That's kind of the 
whole
+  point in using a datagram service */
+   s-s3-wbuf.left = 0;
+   }
return(i);
+   }
s-s3-wbuf.offset+=i;
s-s3-wbuf.left-=i;
}

-- 
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED]  Intel Corporation


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

Re: [openssl.org #1703] Bug report for DTLS

2008-06-18 Thread Ariel Salomon 


If I recall correctly, when I saw this problem the issue was sending 
user data larger than the MTU detected during handshake negotiation.  
The DTLS code seems to have some inconsistencies related to this, as MTU 
should not have an effect on user data -- the protocol only provides 
fragmentation of handshakes.


 - Ariel

Joel Reardon via RT wrote:

For version 0.9.8h
in do_dtls1_write()

in the block:

/* first check if there is a SSL3_BUFFER still being written
  * out.  This will happen with non blocking IO */
if (s-s3-wbuf.left != 0)
{
OPENSSL_assert(0); /* XDTLS:  want to see if we ever get
here */
return(ssl3_write_pending(s,type,buf,len));
}


To answer the comment's question: Yes, we do get there.

Regards,
Joel Reardon

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

  



--
- Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / [EMAIL PROTECTED]

RTI - The Real-Time Middleware Experts


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

Re: [openssl.org #1703] Bug report for DTLS

2008-06-18 Thread Joel Reardon via RT 
Thanks,

I have MTU discover on, and am testing the peers using a single computers 
loopback. I'll try setting the MTU using a ctrl() and do some 
investigations to see if thats the problem. Anyhow, the existance 
of code following an assert(0) and the 
comment suggesting that the authors added it during testing to see if the 
clause is reached suggests that either its unfinished, at least 
likely untested, or the assertion is unnessary (or, at least minimally, 
the code that follows it is unnessarily); I thought I'd bring that up. 
I'm having other bugs/troubles with DTLS as I'm using it for an amibition 
project. In the coming weeks I'll either present cogent bug 
reports/examples programs, or fix it myself depending on how long this 
Thesis takes to write and submit the patch.

Joel

On Wed, 18 Jun 2008, Ariel Salomon via RT wrote:


 If I recall correctly, when I saw this problem the issue was sending
 user data larger than the MTU detected during handshake negotiation.
 The DTLS code seems to have some inconsistencies related to this, as MTU
 should not have an effect on user data -- the protocol only provides
 fragmentation of handshakes.

  - Ariel

 Joel Reardon via RT wrote:
 For version 0.9.8h
 in do_dtls1_write()

 in the block:

 /* first check if there is a SSL3_BUFFER still being written
   * out.  This will happen with non blocking IO */
 if (s-s3-wbuf.left != 0)
 {
 OPENSSL_assert(0); /* XDTLS:  want to see if we ever get
 here */
 return(ssl3_write_pending(s,type,buf,len));
 }


 To answer the comment's question: Yes, we do get there.

 Regards,
 Joel Reardon

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




 -- 
 - Ariel Salomon / Senior Software Engineer
 Real-Time Innovations (RTI) / www.rti.com
 408 990-7439 / [EMAIL PROTECTED]

 RTI - The Real-Time Middleware Experts





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