Re: LibreSSL 2.0.3 released

2014-07-23 Thread Dongsheng Song
On Tue, Jul 22, 2014 at 10:01 AM, Bob Beck b...@openbsd.org wrote:

 We have released an update, LibreSSL 2.0.3 - which should
 be arriving in the LibreSSL directory of an OpenBSD mirror near
 you very soon.

 This release includes a number of portability fixes based on the
 the feedback we have received from the community. It also includes
 some improvements to the fork detection support.

 As noted before, we welcome feedback from the broader community.

 Enjoy,

 -Bob



Thanks, all tests passed on Debian 6, 7 and 8 (testing):

$ ./configure --prefix=/opt/libressl
$ make -j4
$ make check

Testsuite summary for libressl 2.0.3

# TOTAL: 42
# PASS:  42
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Regards,
Dongsheng



[PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Hanno Böck
Hi,

Quick background: Some router firmwares from F5 have a bug that they
fail if the SSL handshake is between 256 and 511 bytes.

Following up that openssl and other major ssl implementations
introduced a TLS padding extension that does nothing else than padding
the handshake if it is between these sizes.

IMHO this is the wrong way of doing things, because it hides bugs
instead of fixing them. And a bunch of alike workarounds in the past
are one of the reasons TLS is such a mess these days.
Also, there have already been devices found that break with this
workaround because they fail if the ssl handshake is above 512 bytes
[3].

openssl unconditionally enables the padding extension. I propose a
simple step: Just remove it from libressl.



[1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html

cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42
diff -Naur libressl-2.0.3/include/openssl/tls1.h libressl-2.0.3-1/include/openssl/tls1.h
--- libressl-2.0.3/include/openssl/tls1.h	2014-07-11 18:50:56.0 +0200
+++ libressl-2.0.3-1/include/openssl/tls1.h	2014-07-23 10:12:34.081669530 +0200
@@ -230,12 +230,6 @@
 /* ExtensionType value from RFC5620 */
 #define TLSEXT_TYPE_heartbeat	15
 
-/* ExtensionType value for TLS padding extension.
- * http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
- * http://tools.ietf.org/html/draft-agl-tls-padding-03
- */
-#define TLSEXT_TYPE_padding	21
-
 /* ExtensionType value from RFC4507 */
 #define TLSEXT_TYPE_session_ticket		35
 
diff -Naur libressl-2.0.3/ssl/t1_lib.c libressl-2.0.3-1/ssl/t1_lib.c
--- libressl-2.0.3/ssl/t1_lib.c	2014-07-14 01:04:03.0 +0200
+++ libressl-2.0.3-1/ssl/t1_lib.c	2014-07-23 10:12:13.006933000 +0200
@@ -635,35 +635,6 @@
 	}
 #endif
 
-#ifdef TLSEXT_TYPE_padding
-	/* Add padding to workaround bugs in F5 terminators.
-	 * See https://tools.ietf.org/html/draft-agl-tls-padding-03
-	 *
-	 * NB: because this code works out the length of all existing
-	 * extensions it MUST always appear last.
-	 */
-	{
-		int hlen = ret - (unsigned char *)s-init_buf-data;
-	/* The code in s23_clnt.c to build ClientHello messages includes the
-	 * 5-byte record header in the buffer, while the code in s3_clnt.c does
-	 * not. */
-		if (s-state == SSL23_ST_CW_CLNT_HELLO_A)
-			hlen -= 5;
-		if (hlen  0xff  hlen  0x200) {
-			hlen = 0x200 - hlen;
-			if (hlen = 4)
-hlen -= 4;
-			else
-hlen = 0;
-
-			s2n(TLSEXT_TYPE_padding, ret);
-			s2n(hlen, ret);
-			memset(ret, 0, hlen);
-			ret += hlen;
-		}
-	}
-#endif
-
 	if ((extdatalen = ret - p - 2) == 0)
 		return p;
 


signature.asc
Description: PGP signature


Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Loganaden Velvindron
On Wed, Jul 23, 2014 at 10:20:23AM +0200, Hanno B?ck wrote:
 Hi,
 
 Quick background: Some router firmwares from F5 have a bug that they
 fail if the SSL handshake is between 256 and 511 bytes.

F5 should issue fixes for their firmware.

 
 Following up that openssl and other major ssl implementations
 introduced a TLS padding extension that does nothing else than padding
 the handshake if it is between these sizes.
 
 IMHO this is the wrong way of doing things, because it hides bugs
 instead of fixing them. And a bunch of alike workarounds in the past
 are one of the reasons TLS is such a mess these days.
 Also, there have already been devices found that break with this
 workaround because they fail if the ssl handshake is above 512 bytes
 [3].
 
 openssl unconditionally enables the padding extension. I propose a
 simple step: Just remove it from libressl.
 
 
 
 [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
 [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
 [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html
 
 cu,
 -- 
 Hanno B?ck
 http://hboeck.de/
 
 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42

 diff -Naur libressl-2.0.3/include/openssl/tls1.h 
 libressl-2.0.3-1/include/openssl/tls1.h
 --- libressl-2.0.3/include/openssl/tls1.h 2014-07-11 18:50:56.0 
 +0200
 +++ libressl-2.0.3-1/include/openssl/tls1.h   2014-07-23 10:12:34.081669530 
 +0200
 @@ -230,12 +230,6 @@
  /* ExtensionType value from RFC5620 */
  #define TLSEXT_TYPE_heartbeat15
  
 -/* ExtensionType value for TLS padding extension.
 - * 
 http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
 - * http://tools.ietf.org/html/draft-agl-tls-padding-03
 - */
 -#define TLSEXT_TYPE_padding  21
 -
  /* ExtensionType value from RFC4507 */
  #define TLSEXT_TYPE_session_ticket   35
  
 diff -Naur libressl-2.0.3/ssl/t1_lib.c libressl-2.0.3-1/ssl/t1_lib.c
 --- libressl-2.0.3/ssl/t1_lib.c   2014-07-14 01:04:03.0 +0200
 +++ libressl-2.0.3-1/ssl/t1_lib.c 2014-07-23 10:12:13.006933000 +0200
 @@ -635,35 +635,6 @@
   }
  #endif
  
 -#ifdef TLSEXT_TYPE_padding
 - /* Add padding to workaround bugs in F5 terminators.
 -  * See https://tools.ietf.org/html/draft-agl-tls-padding-03
 -  *
 -  * NB: because this code works out the length of all existing
 -  * extensions it MUST always appear last.
 -  */
 - {
 - int hlen = ret - (unsigned char *)s-init_buf-data;
 - /* The code in s23_clnt.c to build ClientHello messages includes the
 -  * 5-byte record header in the buffer, while the code in s3_clnt.c does
 -  * not. */
 - if (s-state == SSL23_ST_CW_CLNT_HELLO_A)
 - hlen -= 5;
 - if (hlen  0xff  hlen  0x200) {
 - hlen = 0x200 - hlen;
 - if (hlen = 4)
 - hlen -= 4;
 - else
 - hlen = 0;
 -
 - s2n(TLSEXT_TYPE_padding, ret);
 - s2n(hlen, ret);
 - memset(ret, 0, hlen);
 - ret += hlen;
 - }
 - }
 -#endif
 -
   if ((extdatalen = ret - p - 2) == 0)
   return p;
  



Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Hanno Böck
On Wed, 23 Jul 2014 01:28:45 -0700
Loganaden Velvindron lo...@elandsys.com wrote:

 On Wed, Jul 23, 2014 at 10:20:23AM +0200, Hanno B?ck wrote:
  Quick background: Some router firmwares from F5 have a bug that they
  fail if the SSL handshake is between 256 and 511 bytes.
 
 F5 should issue fixes for their firmware.

They did. The problem is people not updating their firmware.


-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


signature.asc
Description: PGP signature


Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Stuart Henderson
On 2014/07/23 10:36, Hanno Böck wrote:
 On Wed, 23 Jul 2014 01:28:45 -0700
 Loganaden Velvindron lo...@elandsys.com wrote:
 
  On Wed, Jul 23, 2014 at 10:20:23AM +0200, Hanno B?ck wrote:
   Quick background: Some router firmwares from F5 have a bug that they
   fail if the SSL handshake is between 256 and 511 bytes.
  
  F5 should issue fixes for their firmware.
 
 They did. The problem is people not updating their firmware.

That needs a support contract. There are likely to be many website
operators with a value-for-money ;) procurement policy unlikely to
have access to updated firmware and they won't know about the problem
because it will only show up client-side with clients that don't
mitigate the bug.

I wonder if Google could make available any stats on how common
the bad firmware versions are. I imagine that they would know and
that it would be pretty significant to be worth going to the effort
of producing an internet-draft and getting a diff into OpenSSL.




resume vs wsmoused vs X vs pms

2014-07-23 Thread Martin Pieuchot
Diff below changes pms(4) to make sure only one thread can change the
state, thus generating I/O, of the underlying device at the same time.

It fixes a race easily reproducible when a machine having wsmoused(8)
and X running is resumed.  The problem is that the first program trying
to activate the mouse sleeps in pms_change_state() before changing the
state of the device.  At this moment, the second program also tries to
enable the device and enqueue more commands before going to sleep...

While setting the state before going to sleep would also prevent this
particular race, it won't prevent the (very unlikely) scenario where a
program tries to disable the device while another one tries to enable
it.

Other mouse devices parent of wsmouse(4) might be subject to similar
races, but pms(4) is special because it can be the parent of two
wsmouses pointing to the same softc!  So at this stage of the release
cycle I think it is safer to only fix this particular and problematic
device.

ok?

Index: pms.c
===
RCS file: /home/ncvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.52
diff -u -p -r1.52 pms.c
--- pms.c   12 Jul 2014 18:48:52 -  1.52
+++ pms.c   23 Jul 2014 11:00:40 -
@@ -26,6 +26,7 @@
 
 #include sys/param.h
 #include sys/systm.h
+#include sys/rwlock.h
 #include sys/device.h
 #include sys/ioctl.h
 #include sys/malloc.h
@@ -148,6 +149,8 @@ struct pms_softc {  /* driver status inf
 #define PMS_STATE_ENABLED  1
 #define PMS_STATE_SUSPENDED2
 
+   struct rwlock sc_state_lock;
+
int sc_dev_enable;
 #define PMS_DEV_IGNORE 0x00
 #define PMS_DEV_PRIMARY0x01
@@ -762,8 +765,13 @@ int
 pms_enable(void *v)
 {
struct pms_softc *sc = v;
+   int rv;
+
+   rw_enter_write(sc-sc_state_lock);
+   rv = pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_PRIMARY);
+   rw_exit_write(sc-sc_state_lock);
 
-   return pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_PRIMARY);
+   return (rv);
 }
 
 void
@@ -771,7 +779,9 @@ pms_disable(void *v)
 {
struct pms_softc *sc = v;
 
+   rw_enter_write(sc-sc_state_lock);
pms_change_state(sc, PMS_STATE_DISABLED, PMS_DEV_PRIMARY);
+   rw_exit_write(sc-sc_state_lock);
 }
 
 int
@@ -789,8 +799,13 @@ int
 pms_sec_enable(void *v)
 {
struct pms_softc *sc = v;
+   int rv;
+
+   rw_enter_write(sc-sc_state_lock);
+   rv = pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_SECONDARY);
+   rw_exit_write(sc-sc_state_lock);
 
-   return (pms_change_state(sc, PMS_STATE_ENABLED, PMS_DEV_SECONDARY));
+   return (rv);
 }
 
 void
@@ -798,7 +813,9 @@ pms_sec_disable(void *v)
 {
struct pms_softc *sc = v;
 
+   rw_enter_write(sc-sc_state_lock);
pms_change_state(sc, PMS_STATE_DISABLED, PMS_DEV_SECONDARY);
+   rw_exit_write(sc-sc_state_lock);
 }
 
 int



Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Bob Beck
An interesting thought Hanno - do we know what other implementations
(Polar, GnuTLS, etc.) do by default?

I'm inclined to agree that it never should have been done. Having said
that, before we nuke it we kind of
need to know if this is has become de-facto standard behaviour thanks
to OpenSSL doing this in the
first place.

-Bob


On Wed, Jul 23, 2014 at 2:20 AM, Hanno Böck ha...@hboeck.de wrote:
 Hi,

 Quick background: Some router firmwares from F5 have a bug that they
 fail if the SSL handshake is between 256 and 511 bytes.

 Following up that openssl and other major ssl implementations
 introduced a TLS padding extension that does nothing else than padding
 the handshake if it is between these sizes.

 IMHO this is the wrong way of doing things, because it hides bugs
 instead of fixing them. And a bunch of alike workarounds in the past
 are one of the reasons TLS is such a mess these days.
 Also, there have already been devices found that break with this
 workaround because they fail if the ssl handshake is above 512 bytes
 [3].

 openssl unconditionally enables the padding extension. I propose a
 simple step: Just remove it from libressl.



 [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
 [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
 [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html

 cu,
 --
 Hanno Böck
 http://hboeck.de/

 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42



Re: LibreSSL 2.0.3 released

2014-07-23 Thread Martin Hecht
On 07/23/2014 10:09 AM, Dongsheng Song wrote:
 On Tue, Jul 22, 2014 at 10:01 AM, Bob Beck b...@openbsd.org wrote:
 We have released an update, LibreSSL 2.0.3 - which should
 be arriving in the LibreSSL directory of an OpenBSD mirror near
 you very soon.

 This release includes a number of portability fixes based on the
 the feedback we have received from the community. It also includes
 some improvements to the fork detection support.

 As noted before, we welcome feedback from the broader community.

 Enjoy,

 -Bob


 Thanks, all tests passed on Debian 6, 7 and 8 (testing):

 $ ./configure --prefix=/opt/libressl
 $ make -j4
 $ make check
 
 Testsuite summary for libressl 2.0.3
 
 # TOTAL: 42
 # PASS:  42
 # SKIP:  0
 # XFAIL: 0
 # FAIL:  0
 # XPASS: 0
 # ERROR: 0
 

 Regards,
 Dongsheng

...the same (PASS: 42) for

Ubuntu 12.04
Scientific Linux 6.5
SLES 11 SP 1 LTSS

is such a feedback useful for the developers? The installations have a
particular selection of installed packages, which may differ from a
standard installation.


Martin



Re: LibreSSL 2.0.3 released

2014-07-23 Thread Brent Cook

On Jul 23, 2014, at 8:16 AM, Martin Hecht he...@hlrs.de wrote:

 On 07/23/2014 10:09 AM, Dongsheng Song wrote:
 On Tue, Jul 22, 2014 at 10:01 AM, Bob Beck b...@openbsd.org wrote:
 We have released an update, LibreSSL 2.0.3 - which should
 be arriving in the LibreSSL directory of an OpenBSD mirror near
 you very soon.
 
 This release includes a number of portability fixes based on the
 the feedback we have received from the community. It also includes
 some improvements to the fork detection support.
 
 As noted before, we welcome feedback from the broader community.
 
 Enjoy,
 
 -Bob
 
 
 Thanks, all tests passed on Debian 6, 7 and 8 (testing):
 
 $ ./configure --prefix=/opt/libressl
 $ make -j4
 $ make check
 
 Testsuite summary for libressl 2.0.3
 
 # TOTAL: 42
 # PASS:  42
 # SKIP:  0
 # XFAIL: 0
 # FAIL:  0
 # XPASS: 0
 # ERROR: 0
 
 
 Regards,
 Dongsheng
 
 ...the same (PASS: 42) for
 
 Ubuntu 12.04
 Scientific Linux 6.5
 SLES 11 SP 1 LTSS
 
 is such a feedback useful for the developers? The installations have a
 particular selection of installed packages, which may differ from a
 standard installation.
 
 
 Martin
 

Thanks Martin and Dongsheng,

SLES is one I had not tried yet; glad to know, as its compiler settings can 
sometimes be more strict by default.

We will hopefully at some point have automated build / regression testing, but 
until then such reports are appreciated.

 - Brent




Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Brent Cook

On Jul 23, 2014, at 8:04 AM, Bob Beck b...@obtuse.com wrote:

 An interesting thought Hanno - do we know what other implementations
 (Polar, GnuTLS, etc.) do by default?

PolarSSL does not generate the extension, but tolerates it on the server side.

GnuTLS generates it if you enable the %COMPAT or %DUMBFW priority strings.

 I'm inclined to agree that it never should have been done. Having said
 that, before we nuke it we kind of
 need to know if this is has become de-facto standard behaviour thanks
 to OpenSSL doing this in the
 first place.
 
 -Bob
 
 
 On Wed, Jul 23, 2014 at 2:20 AM, Hanno Böck ha...@hboeck.de wrote:
 Hi,
 
 Quick background: Some router firmwares from F5 have a bug that they
 fail if the SSL handshake is between 256 and 511 bytes.
 
 Following up that openssl and other major ssl implementations
 introduced a TLS padding extension that does nothing else than padding
 the handshake if it is between these sizes.
 
 IMHO this is the wrong way of doing things, because it hides bugs
 instead of fixing them. And a bunch of alike workarounds in the past
 are one of the reasons TLS is such a mess these days.
 Also, there have already been devices found that break with this
 workaround because they fail if the ssl handshake is above 512 bytes
 [3].
 
 openssl unconditionally enables the padding extension. I propose a
 simple step: Just remove it from libressl.
 
 
 
 [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
 [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
 [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html
 
 cu,
 --
 Hanno Böck
 http://hboeck.de/
 
 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42
 




IEEE80211_DEBUG

2014-07-23 Thread Nathanael Rensen
The IEEE80211_DEBUG kernel option needs a little help to compile.

Index: ieee80211_pae_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_pae_input.c,v
retrieving revision 1.19
diff -u -p -r1.19 ieee80211_pae_input.c
--- ieee80211_pae_input.c   22 Jul 2014 11:06:10 -  1.19
+++ ieee80211_pae_input.c   23 Jul 2014 14:25:22 -
@@ -978,7 +978,7 @@ ieee80211_recv_group_msg2(struct ieee802
 
/* discard if we're not expecting this message */
if (ni-ni_rsn_gstate != RSNA_REKEYNEGOTIATING) {
-   DPRINTF((%s: unexpected in state: %d\n, ni-ni_rsn_gstate));
+   DPRINTF((unexpected in state: %d\n, ni-ni_rsn_gstate));
return;
}
if (BE_READ_8(key-replaycnt) != ni-ni_replaycnt) {

Also a plug for a previous diff that may have fallen through the cracks:

http://marc.info/?l=openbsd-techm=140421855720135

Nathanael



Re: LibreSSL 2.0.3 released

2014-07-23 Thread Michał Markowski
2014-07-23 15:16 GMT+02:00 Martin Hecht he...@hlrs.de:
 ...the same (PASS: 42) for

 Ubuntu 12.04
 Scientific Linux 6.5
 SLES 11 SP 1 LTSS

Count in current Arch Linux (x86_64):

# TOTAL: 42
# PASS:  42
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

-- 
Michał Markowski



Re: IEEE80211_DEBUG

2014-07-23 Thread Chris Cappuccio
Nathanael Rensen [nathan...@list.polymorpheus.com] wrote:
 The IEEE80211_DEBUG kernel option needs a little help to compile.
 
 Index: ieee80211_pae_input.c
 ===
 RCS file: /cvs/src/sys/net80211/ieee80211_pae_input.c,v
 retrieving revision 1.19
 diff -u -p -r1.19 ieee80211_pae_input.c
 --- ieee80211_pae_input.c 22 Jul 2014 11:06:10 -  1.19
 +++ ieee80211_pae_input.c 23 Jul 2014 14:25:22 -
 @@ -978,7 +978,7 @@ ieee80211_recv_group_msg2(struct ieee802
  
   /* discard if we're not expecting this message */
   if (ni-ni_rsn_gstate != RSNA_REKEYNEGOTIATING) {
 - DPRINTF((%s: unexpected in state: %d\n, ni-ni_rsn_gstate));
 + DPRINTF((unexpected in state: %d\n, ni-ni_rsn_gstate));

probably want this:
+   DPRINTF((%s: unexpected in state: %d\n, ic-ic_if.if_xname,
+   ni-ni_rsn_gstate));



Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Bob Beck
I think we can consider removing it, but I think it might be best to
wait until after the forthcoming OpenBSD release.

On Wed, Jul 23, 2014 at 8:01 AM, Brent Cook bust...@gmail.com wrote:

 On Jul 23, 2014, at 8:04 AM, Bob Beck b...@obtuse.com wrote:

 An interesting thought Hanno - do we know what other implementations
 (Polar, GnuTLS, etc.) do by default?

 PolarSSL does not generate the extension, but tolerates it on the server side.

 GnuTLS generates it if you enable the %COMPAT or %DUMBFW priority strings.

 I'm inclined to agree that it never should have been done. Having said
 that, before we nuke it we kind of
 need to know if this is has become de-facto standard behaviour thanks
 to OpenSSL doing this in the
 first place.

 -Bob


 On Wed, Jul 23, 2014 at 2:20 AM, Hanno Böck ha...@hboeck.de wrote:
 Hi,

 Quick background: Some router firmwares from F5 have a bug that they
 fail if the SSL handshake is between 256 and 511 bytes.

 Following up that openssl and other major ssl implementations
 introduced a TLS padding extension that does nothing else than padding
 the handshake if it is between these sizes.

 IMHO this is the wrong way of doing things, because it hides bugs
 instead of fixing them. And a bunch of alike workarounds in the past
 are one of the reasons TLS is such a mess these days.
 Also, there have already been devices found that break with this
 workaround because they fail if the ssl handshake is above 512 bytes
 [3].

 openssl unconditionally enables the padding extension. I propose a
 simple step: Just remove it from libressl.



 [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
 [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
 [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html

 cu,
 --
 Hanno Böck
 http://hboeck.de/

 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42





Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Ted Unangst
On Wed, Jul 23, 2014 at 10:20, Hanno Böck wrote:
 Hi,
 
 Quick background: Some router firmwares from F5 have a bug that they
 fail if the SSL handshake is between 256 and 511 bytes.
 
 Following up that openssl and other major ssl implementations
 introduced a TLS padding extension that does nothing else than padding
 the handshake if it is between these sizes.

hmm. the workaround isn't particularly intrusive imo. also, while our
policy has been minimal workarounds, i think that applies to the host
operating system. interop compat is a different beast.

 IMHO this is the wrong way of doing things, because it hides bugs
 instead of fixing them. And a bunch of alike workarounds in the past
 are one of the reasons TLS is such a mess these days.

i generally agree, but to play devil's advocate, i don't see this as a
quality of implementation issue.

 Also, there have already been devices found that break with this
 workaround because they fail if the ssl handshake is above 512 bytes

well, the same logic would demand that they fix those devices, too,
right? :)



Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Theo de Raadt
  Quick background: Some router firmwares from F5 have a bug that they
  fail if the SSL handshake is between 256 and 511 bytes.
  
  Following up that openssl and other major ssl implementations
  introduced a TLS padding extension that does nothing else than padding
  the handshake if it is between these sizes.
 
 hmm. the workaround isn't particularly intrusive imo. also, while our
 policy has been minimal workarounds, i think that applies to the host
 operating system. interop compat is a different beast.

Indeed.

Removal of this code would require proof that it causes no harm.

I am quite frankly sick of being told that we are removing code
we don't understand, when it is not true.

In this case, we have no idea how many broken F5's there are out
there, so there is no reason to remove this code.  Proving the case
would be up to you Hanno.  You can start by trying to suggest that
the OpenSSL folk should remove it...

 



Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Claus Assmann
On Wed, Jul 23, 2014, Ted Unangst wrote:
 On Wed, Jul 23, 2014 at 10:20, Hanno B??ck wrote:

  Quick background: Some router firmwares from F5 have a bug that they
  fail if the SSL handshake is between 256 and 511 bytes.

Is this the same problem discussed in
Message-ID: 20140410170056.gi12...@mournblade.imrryr.org
on the openssl-users list?
Subject: Re: openssl update 1.0.1f to 1.0.1g broke sendmail
(SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)

  Following up that openssl and other major ssl implementations
  introduced a TLS padding extension that does nothing else than padding
  the handshake if it is between these sizes.

 hmm. the workaround isn't particularly intrusive imo. also, while our
 policy has been minimal workarounds, i think that applies to the host
 operating system. interop compat is a different beast.

Yes -- if it is the problem referenced above then it breaks some
other software, i.e., some MTAs.