Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-05 Thread Kaspar Brand
On 31.03.2015 19:12, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/mod_ssl.h
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h
 
 Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1670397r1=1670396r2=1670397view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
 +++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Tue Mar 31 17:12:51 2015
 @@ -283,6 +283,12 @@ static const command_rec ssl_config_cmds
  OpenSSL configuration command)
  #endif
  
 +#if defined(HAVE_TLS_ALPN) || defined(HAVE_TLS_NPN)
 +SSL_CMD_SRV(AlpnPreference, ITERATE,
 +Preference in Application-Layer Protocol Negotiation 
 (ALPN), 
 +protocols are chosed in the specified order)
 +#endif
 +

s/chosed/chosen/ - and please add docs for this to mod_ssl.xml, too.


 Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1670397r1=1670396r2=1670397view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_private.h Tue Mar 31 17:12:51 2015
 @@ -181,6 +181,16 @@
  #define HAVE_TLS_NPN
  #endif
  
 +/* ALPN Protocol Negotiation */
 +#if OPENSSL_VERSION_NUMBER = 0x10002000L  !defined(OPENSSL_NO_TLSEXT)
 +#define HAVE_TLS_ALPN
 +#endif
 +
 +/* Next Protocol Negotiation */
 +#if !defined(OPENSSL_NO_NEXTPROTONEG)  !defined(OPENSSL_NO_TLSEXT)  
 defined(OPENSSL_NPN_NEGOTIATED)
 +#define HAVE_TLS_NPN
 +#endif
 +

Instead of hardcoding OpenSSL version numbers, we should rely on
feature-based detection - in this case, we can use

  #if defined(TLSEXT_TYPE_application_layer_protocol_negotiation)

(see
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b0d6f3c58fc86756574b410cb6a32589477d3954,
the ALPN backport to 1.0.2)

Also, the two  !defined(OPENSSL_NO_TLSEXT) can be dropped, since
we're already in a larger #if !defined(OPENSSL_NO_TLSEXT) ... block.


And with regard to:

On 01.04.2015 22:33, Jim Jagielski wrote:
 Yeah, I agree. Right now, trunk pretty much uses
 
   #ifdef HAVE_TLS_ALPN
   blah blah
   #endif
   #ifdef HAVE_TLS_NPN
   blah2 blah2
   #endif
 
 Instead of
 
   #if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)
 
 so that ripping out NPN would be easier. The question is
 which to use for 2.4...

My vote is clearly for only having ALPN in 2.4 - implementations of
draft protocol versions shouldn't creep into stable httpd
releases, in particular when they have been superseded by a
standards-track RFC meanwhile (RFC 7301 was published in July 2014, and
even Google has announced its plans to drop NPN early next year,
http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html).

Kaspar


Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-02 Thread Stefan Eissing
Any reason to differ from trunk in 2.4? 

The people using spdy already in a 2.4 will most likely have the NPN patch 
deployed, so they'll have it easy with the trunk changes. The only one using 
the alpn patch, I know of, is myself in mod_h2. And that has already been 
adapted.

So, I myself see no reason to not bring the trunk change into 2.4.

 Am 01.04.2015 um 22:33 schrieb Jim Jagielski j...@jagunet.com:
 
 Yeah, I agree. Right now, trunk pretty much uses
 
   #ifdef HAVE_TLS_ALPN
   blah blah
   #endif
   #ifdef HAVE_TLS_NPN
   blah2 blah2
   #endif
 
 Instead of
 
   #if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)
 
 so that ripping out NPN would be easier. The question is
 which to use for 2.4...
 
 On Apr 1, 2015, at 1:59 PM, Stefan Eissing stefan.eiss...@greenbytes.de 
 wrote:
 
 Well, I took the trunk version, diffed to 2.4.12 and made a patch for my 
 sandbox build (removed the non alpn/npn parts). That works for mod_h2 after 
 adding callbacks for the npn stuff. 
 
 I have no real pref to keep npn and alpn separate or not. my thought when 
 merging these was that npn will go away rather soon as alpn is supposed to 
 replace it and is afaik the cryptographically more secure way (i think npn 
 is prone to mitm downgrade attacks). 
 
 cheers,
 Stefan
 
 
 
 Am 01.04.2015 um 19:28 schrieb Jim Jagielski j...@jagunet.com:
 
 Yeah, there is some overlap which I'm trying to grok,
 since trunk had NPN but not ALPN, so I tried to have the
 ALPN stuff self-contained. But not sure if that's the best
 way since, for example, alpn_proposefns is adjusted
 in ssl_callback_AdvertiseNextProtos(), but that is a
 NPN only function in trunk, so it uses npn_proposefns.
 
 I'm thinking that in trunk we shouldn't think of
 NPN and ALPN as distinct.
 
 On Apr 1, 2015, at 12:47 PM, Rainer Jung rainer.j...@kippdata.de wrote:
 
 Hi Stefan,
 
 Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
 Jim,
 
 today I converted your commit to a path on 2.4.12 and tested it with 
 mod_h2. All fine!
 
 Then I got a trouble report that alpn negotiation always selected 
 http/1.1 unless SSLAlpnPreference configured something else. This is 
 due to the deterministic ordering and http/1.1.  h2. So, I made a 
 slight modification, attached below.
 
 Maybe related but concerning NPN: There was a difference between the NPN 
 parts of your original Bugzilla attachment and what was already in mod_ssl 
 trunk and therefore was not applied. In your attachment, there was some 
 code for sorting in ssl_callback_AdvertiseNextProtos() which IMHO does not 
 exist in trunk. Is that part necessary?
 
 A second difference: your original addition to ssl_engine_io.c had the NPN 
 and the ALPN parts merged in the same code block. In trunk those are now 
 two separate pieces coming after each other.
 
 --- modules/ssl/ssl_engine_kernel.c2015-04-01 15:23:48.0 +0200
 +++ 
 ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c
 2015-04-01 17:53:03.0 +0200
 @@ -2177,7 +2152,7 @@
 }
 
 /*
 - * Compare to ALPN protocol proposal. Result is similar to strcmp():
 + * Compare two ALPN protocol proposal. Result is similar to strcmp():
 * 0 gives same precedence, 0 means proto1 is prefered.
 */
 static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
 @@ -2254,14 +2229,8 @@
   i += plen;
   }
 
 -/* Regardless of installed hooks, the http/1.1 protocol is always
 - * supported by us. Add it to the proposals if the client also
 - * offers it. */
   proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
sizeof(char *));
 -if (ssl_array_index(client_protos, alpn_http1) = 0) {
 -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
 -}
 
   if (sslconn-alpn_proposefns != NULL) {
   /* Invoke our alpn_propos_proto hooks, giving other modules a 
 chance to
 @@ -2280,9 +2249,16 @@
   }
 
   if (proposed_protos-nelts = 0) {
 -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 -  none of the client alpn protocols are supported);
 -return SSL_TLSEXT_ERR_ALERT_FATAL;
 +/* Regardless of installed hooks, the http/1.1 protocol is always
 + * supported by us. Choose it if none other matches. */
 +if (ssl_array_index(client_protos, alpn_http1)  0) {
 +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 +  none of the client alpn protocols are 
 supported);
 +return SSL_TLSEXT_ERR_ALERT_FATAL;
 +}
 +*out = (const unsigned char*)alpn_http1;
 +*outlen = (unsigned char)strlen(alpn_http1);
 +return SSL_TLSEXT_ERR_OK;
   }
 
   /* Now select the most preferred protocol from the proposals. */
 
 

green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782





Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-02 Thread Paul Querna
It seems reasonable to focus on ALPN support, and generally dropping
NPN from trunk.  NPN is already on a decline, and won't be used going
forward.

On Thu, Apr 2, 2015 at 12:44 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
 Any reason to differ from trunk in 2.4?

 The people using spdy already in a 2.4 will most likely have the NPN patch 
 deployed, so they'll have it easy with the trunk changes. The only one using 
 the alpn patch, I know of, is myself in mod_h2. And that has already been 
 adapted.

 So, I myself see no reason to not bring the trunk change into 2.4.

 Am 01.04.2015 um 22:33 schrieb Jim Jagielski j...@jagunet.com:

 Yeah, I agree. Right now, trunk pretty much uses

   #ifdef HAVE_TLS_ALPN
   blah blah
   #endif
   #ifdef HAVE_TLS_NPN
   blah2 blah2
   #endif

 Instead of

   #if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)

 so that ripping out NPN would be easier. The question is
 which to use for 2.4...

 On Apr 1, 2015, at 1:59 PM, Stefan Eissing stefan.eiss...@greenbytes.de 
 wrote:

 Well, I took the trunk version, diffed to 2.4.12 and made a patch for my 
 sandbox build (removed the non alpn/npn parts). That works for mod_h2 after 
 adding callbacks for the npn stuff.

 I have no real pref to keep npn and alpn separate or not. my thought when 
 merging these was that npn will go away rather soon as alpn is supposed to 
 replace it and is afaik the cryptographically more secure way (i think npn 
 is prone to mitm downgrade attacks).

 cheers,
 Stefan



 Am 01.04.2015 um 19:28 schrieb Jim Jagielski j...@jagunet.com:

 Yeah, there is some overlap which I'm trying to grok,
 since trunk had NPN but not ALPN, so I tried to have the
 ALPN stuff self-contained. But not sure if that's the best
 way since, for example, alpn_proposefns is adjusted
 in ssl_callback_AdvertiseNextProtos(), but that is a
 NPN only function in trunk, so it uses npn_proposefns.

 I'm thinking that in trunk we shouldn't think of
 NPN and ALPN as distinct.

 On Apr 1, 2015, at 12:47 PM, Rainer Jung rainer.j...@kippdata.de wrote:

 Hi Stefan,

 Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
 Jim,

 today I converted your commit to a path on 2.4.12 and tested it with 
 mod_h2. All fine!

 Then I got a trouble report that alpn negotiation always selected 
 http/1.1 unless SSLAlpnPreference configured something else. This is 
 due to the deterministic ordering and http/1.1.  h2. So, I made a 
 slight modification, attached below.

 Maybe related but concerning NPN: There was a difference between the NPN 
 parts of your original Bugzilla attachment and what was already in 
 mod_ssl trunk and therefore was not applied. In your attachment, there 
 was some code for sorting in ssl_callback_AdvertiseNextProtos() which 
 IMHO does not exist in trunk. Is that part necessary?

 A second difference: your original addition to ssl_engine_io.c had the 
 NPN and the ALPN parts merged in the same code block. In trunk those are 
 now two separate pieces coming after each other.

 --- modules/ssl/ssl_engine_kernel.c2015-04-01 15:23:48.0 
 +0200
 +++ 
 ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c
 2015-04-01 17:53:03.0 +0200
 @@ -2177,7 +2152,7 @@
 }

 /*
 - * Compare to ALPN protocol proposal. Result is similar to strcmp():
 + * Compare two ALPN protocol proposal. Result is similar to strcmp():
 * 0 gives same precedence, 0 means proto1 is prefered.
 */
 static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
 @@ -2254,14 +2229,8 @@
   i += plen;
   }

 -/* Regardless of installed hooks, the http/1.1 protocol is always
 - * supported by us. Add it to the proposals if the client also
 - * offers it. */
   proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
sizeof(char *));
 -if (ssl_array_index(client_protos, alpn_http1) = 0) {
 -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
 -}

   if (sslconn-alpn_proposefns != NULL) {
   /* Invoke our alpn_propos_proto hooks, giving other modules a 
 chance to
 @@ -2280,9 +2249,16 @@
   }

   if (proposed_protos-nelts = 0) {
 -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 -  none of the client alpn protocols are 
 supported);
 -return SSL_TLSEXT_ERR_ALERT_FATAL;
 +/* Regardless of installed hooks, the http/1.1 protocol is 
 always
 + * supported by us. Choose it if none other matches. */
 +if (ssl_array_index(client_protos, alpn_http1)  0) {
 +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 +  none of the client alpn protocols are 
 supported);
 +return SSL_TLSEXT_ERR_ALERT_FATAL;
 +}
 +*out = (const unsigned char*)alpn_http1;
 +*outlen = (unsigned char)strlen(alpn_http1);
 +return SSL_TLSEXT_ERR_OK;
   }

   /* Now select the most preferred protocol from 

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Stefan Eissing
Jim,

today I converted your commit to a path on 2.4.12 and tested it with mod_h2. 
All fine!

Then I got a trouble report that alpn negotiation always selected http/1.1 
unless SSLAlpnPreference configured something else. This is due to the 
deterministic ordering and http/1.1.  h2. So, I made a slight 
modification, attached below.

Cheers,

  Stefan

--- modules/ssl/ssl_engine_kernel.c 2015-04-01 15:23:48.0 +0200
+++ ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c 
2015-04-01 17:53:03.0 +0200
@@ -2177,7 +2152,7 @@
 }
 
 /*
- * Compare to ALPN protocol proposal. Result is similar to strcmp():
+ * Compare two ALPN protocol proposal. Result is similar to strcmp():
  * 0 gives same precedence, 0 means proto1 is prefered.
  */
 static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
@@ -2254,14 +2229,8 @@
 i += plen;
 }
 
-/* Regardless of installed hooks, the http/1.1 protocol is always
- * supported by us. Add it to the proposals if the client also
- * offers it. */
 proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
  sizeof(char *));
-if (ssl_array_index(client_protos, alpn_http1) = 0) {
-APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
-}
 
 if (sslconn-alpn_proposefns != NULL) {
 /* Invoke our alpn_propos_proto hooks, giving other modules a chance to
@@ -2280,9 +2249,16 @@
 }
 
 if (proposed_protos-nelts = 0) {
-ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
-  none of the client alpn protocols are supported);
-return SSL_TLSEXT_ERR_ALERT_FATAL;
+/* Regardless of installed hooks, the http/1.1 protocol is always
+ * supported by us. Choose it if none other matches. */
+if (ssl_array_index(client_protos, alpn_http1)  0) {
+ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
+  none of the client alpn protocols are supported);
+return SSL_TLSEXT_ERR_ALERT_FATAL;
+}
+*out = (const unsigned char*)alpn_http1;
+*outlen = (unsigned char)strlen(alpn_http1);
+return SSL_TLSEXT_ERR_OK;
 }
 
 /* Now select the most preferred protocol from the proposals. */



httpd-trunk2.unified.diff.patch
Description: Binary data

 Am 31.03.2015 um 21:12 schrieb Jim Jagielski j...@jagunet.com:
 
 Hmmm.. missed a patch.
 
 r1670434
 On Mar 31, 2015, at 2:28 PM, Jim Jagielski j...@jagunet.com wrote:
 
 Hmmm... let me double check.
 
 On Mar 31, 2015, at 2:22 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 08:08 PM, Jim Jagielski wrote:
 They are used by mod_spdy and/or mod_h2..., iirc
 
 They use private structures of mod_ssl directly? That does not sound like a 
 good idea.
 
 Regards
 
 Rüdiger
 
 
 On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 07:12 PM, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/mod_ssl.h
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h
 
 
 I don't know if I miss the obvious, but where do we use
 
 ssl_alpn_pref
 alpn_proposefns
 
 ?
 
 I can only see that we set it, but I fail to see where it is used.
 
 Regards
 
 Rüdiger
 
 
 
 

green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782





Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Stefan Eissing
Well, I took the trunk version, diffed to 2.4.12 and made a patch for my 
sandbox build (removed the non alpn/npn parts). That works for mod_h2 after 
adding callbacks for the npn stuff. 

I have no real pref to keep npn and alpn separate or not. my thought when 
merging these was that npn will go away rather soon as alpn is supposed to 
replace it and is afaik the cryptographically more secure way (i think npn is 
prone to mitm downgrade attacks). 

cheers,
  Stefan



 Am 01.04.2015 um 19:28 schrieb Jim Jagielski j...@jagunet.com:
 
 Yeah, there is some overlap which I'm trying to grok,
 since trunk had NPN but not ALPN, so I tried to have the
 ALPN stuff self-contained. But not sure if that's the best
 way since, for example, alpn_proposefns is adjusted
 in ssl_callback_AdvertiseNextProtos(), but that is a
 NPN only function in trunk, so it uses npn_proposefns.
 
 I'm thinking that in trunk we shouldn't think of
 NPN and ALPN as distinct.
 
 On Apr 1, 2015, at 12:47 PM, Rainer Jung rainer.j...@kippdata.de wrote:
 
 Hi Stefan,
 
 Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
 Jim,
 
 today I converted your commit to a path on 2.4.12 and tested it with 
 mod_h2. All fine!
 
 Then I got a trouble report that alpn negotiation always selected 
 http/1.1 unless SSLAlpnPreference configured something else. This is due 
 to the deterministic ordering and http/1.1.  h2. So, I made a slight 
 modification, attached below.
 
 Maybe related but concerning NPN: There was a difference between the NPN 
 parts of your original Bugzilla attachment and what was already in mod_ssl 
 trunk and therefore was not applied. In your attachment, there was some code 
 for sorting in ssl_callback_AdvertiseNextProtos() which IMHO does not exist 
 in trunk. Is that part necessary?
 
 A second difference: your original addition to ssl_engine_io.c had the NPN 
 and the ALPN parts merged in the same code block. In trunk those are now two 
 separate pieces coming after each other.
 
 --- modules/ssl/ssl_engine_kernel.c2015-04-01 15:23:48.0 +0200
 +++ 
 ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c 
2015-04-01 17:53:03.0 +0200
 @@ -2177,7 +2152,7 @@
 }
 
 /*
 - * Compare to ALPN protocol proposal. Result is similar to strcmp():
 + * Compare two ALPN protocol proposal. Result is similar to strcmp():
  * 0 gives same precedence, 0 means proto1 is prefered.
  */
 static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
 @@ -2254,14 +2229,8 @@
 i += plen;
 }
 
 -/* Regardless of installed hooks, the http/1.1 protocol is always
 - * supported by us. Add it to the proposals if the client also
 - * offers it. */
 proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
  sizeof(char *));
 -if (ssl_array_index(client_protos, alpn_http1) = 0) {
 -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
 -}
 
 if (sslconn-alpn_proposefns != NULL) {
 /* Invoke our alpn_propos_proto hooks, giving other modules a 
 chance to
 @@ -2280,9 +2249,16 @@
 }
 
 if (proposed_protos-nelts = 0) {
 -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 -  none of the client alpn protocols are supported);
 -return SSL_TLSEXT_ERR_ALERT_FATAL;
 +/* Regardless of installed hooks, the http/1.1 protocol is always
 + * supported by us. Choose it if none other matches. */
 +if (ssl_array_index(client_protos, alpn_http1)  0) {
 +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 +  none of the client alpn protocols are 
 supported);
 +return SSL_TLSEXT_ERR_ALERT_FATAL;
 +}
 +*out = (const unsigned char*)alpn_http1;
 +*outlen = (unsigned char)strlen(alpn_http1);
 +return SSL_TLSEXT_ERR_OK;
 }
 
 /* Now select the most preferred protocol from the proposals. */
 


Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Jim Jagielski
Thanks! Added in 1670738.

 On Apr 1, 2015, at 12:22 PM, Stefan Eissing stefan.eiss...@greenbytes.de 
 wrote:
 
 Jim,
 
 today I converted your commit to a path on 2.4.12 and tested it with mod_h2. 
 All fine!
 
 Then I got a trouble report that alpn negotiation always selected http/1.1 
 unless SSLAlpnPreference configured something else. This is due to the 
 deterministic ordering and http/1.1.  h2. So, I made a slight 
 modification, attached below.
 
 Cheers,
 
  Stefan
 
 --- modules/ssl/ssl_engine_kernel.c   2015-04-01 15:23:48.0 +0200
 +++ 
 ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c   
 2015-04-01 17:53:03.0 +0200
 @@ -2177,7 +2152,7 @@
 }
 
 /*
 - * Compare to ALPN protocol proposal. Result is similar to strcmp():
 + * Compare two ALPN protocol proposal. Result is similar to strcmp():
  * 0 gives same precedence, 0 means proto1 is prefered.
  */
 static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
 @@ -2254,14 +2229,8 @@
 i += plen;
 }
 
 -/* Regardless of installed hooks, the http/1.1 protocol is always
 - * supported by us. Add it to the proposals if the client also
 - * offers it. */
 proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
  sizeof(char *));
 -if (ssl_array_index(client_protos, alpn_http1) = 0) {
 -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
 -}
 
 if (sslconn-alpn_proposefns != NULL) {
 /* Invoke our alpn_propos_proto hooks, giving other modules a chance 
 to
 @@ -2280,9 +2249,16 @@
 }
 
 if (proposed_protos-nelts = 0) {
 -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 -  none of the client alpn protocols are supported);
 -return SSL_TLSEXT_ERR_ALERT_FATAL;
 +/* Regardless of installed hooks, the http/1.1 protocol is always
 + * supported by us. Choose it if none other matches. */
 +if (ssl_array_index(client_protos, alpn_http1)  0) {
 +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 +  none of the client alpn protocols are supported);
 +return SSL_TLSEXT_ERR_ALERT_FATAL;
 +}
 +*out = (const unsigned char*)alpn_http1;
 +*outlen = (unsigned char)strlen(alpn_http1);
 +return SSL_TLSEXT_ERR_OK;
 }
 
 /* Now select the most preferred protocol from the proposals. */
 
 httpd-trunk2.unified.diff.patch
 Am 31.03.2015 um 21:12 schrieb Jim Jagielski j...@jagunet.com:
 
 Hmmm.. missed a patch.
 
 r1670434
 On Mar 31, 2015, at 2:28 PM, Jim Jagielski j...@jagunet.com wrote:
 
 Hmmm... let me double check.
 
 On Mar 31, 2015, at 2:22 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 08:08 PM, Jim Jagielski wrote:
 They are used by mod_spdy and/or mod_h2..., iirc
 
 They use private structures of mod_ssl directly? That does not sound like 
 a good idea.
 
 Regards
 
 Rüdiger
 
 
 On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 07:12 PM, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/mod_ssl.h
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h
 
 
 I don't know if I miss the obvious, but where do we use
 
 ssl_alpn_pref
 alpn_proposefns
 
 ?
 
 I can only see that we set it, but I fail to see where it is used.
 
 Regards
 
 Rüdiger
 
 
 
 
 
 green/bytes GmbH
 Hafenweg 16, 48155 Münster, Germany
 Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
 
 
 



Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Jim Jagielski
Yeah, there is some overlap which I'm trying to grok,
since trunk had NPN but not ALPN, so I tried to have the
ALPN stuff self-contained. But not sure if that's the best
way since, for example, alpn_proposefns is adjusted
in ssl_callback_AdvertiseNextProtos(), but that is a
NPN only function in trunk, so it uses npn_proposefns.

I'm thinking that in trunk we shouldn't think of
NPN and ALPN as distinct.

 On Apr 1, 2015, at 12:47 PM, Rainer Jung rainer.j...@kippdata.de wrote:
 
 Hi Stefan,
 
 Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
 Jim,
 
 today I converted your commit to a path on 2.4.12 and tested it with mod_h2. 
 All fine!
 
 Then I got a trouble report that alpn negotiation always selected http/1.1 
 unless SSLAlpnPreference configured something else. This is due to the 
 deterministic ordering and http/1.1.  h2. So, I made a slight 
 modification, attached below.
 
 Maybe related but concerning NPN: There was a difference between the NPN 
 parts of your original Bugzilla attachment and what was already in mod_ssl 
 trunk and therefore was not applied. In your attachment, there was some code 
 for sorting in ssl_callback_AdvertiseNextProtos() which IMHO does not exist 
 in trunk. Is that part necessary?
 
 A second difference: your original addition to ssl_engine_io.c had the NPN 
 and the ALPN parts merged in the same code block. In trunk those are now two 
 separate pieces coming after each other.
 
 --- modules/ssl/ssl_engine_kernel.c  2015-04-01 15:23:48.0 +0200
 +++ 
 ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c  
 2015-04-01 17:53:03.0 +0200
 @@ -2177,7 +2152,7 @@
  }
 
  /*
 - * Compare to ALPN protocol proposal. Result is similar to strcmp():
 + * Compare two ALPN protocol proposal. Result is similar to strcmp():
   * 0 gives same precedence, 0 means proto1 is prefered.
   */
  static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
 @@ -2254,14 +2229,8 @@
  i += plen;
  }
 
 -/* Regardless of installed hooks, the http/1.1 protocol is always
 - * supported by us. Add it to the proposals if the client also
 - * offers it. */
  proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
   sizeof(char *));
 -if (ssl_array_index(client_protos, alpn_http1) = 0) {
 -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
 -}
 
  if (sslconn-alpn_proposefns != NULL) {
  /* Invoke our alpn_propos_proto hooks, giving other modules a 
 chance to
 @@ -2280,9 +2249,16 @@
  }
 
  if (proposed_protos-nelts = 0) {
 -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 -  none of the client alpn protocols are supported);
 -return SSL_TLSEXT_ERR_ALERT_FATAL;
 +/* Regardless of installed hooks, the http/1.1 protocol is always
 + * supported by us. Choose it if none other matches. */
 +if (ssl_array_index(client_protos, alpn_http1)  0) {
 +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 +  none of the client alpn protocols are 
 supported);
 +return SSL_TLSEXT_ERR_ALERT_FATAL;
 +}
 +*out = (const unsigned char*)alpn_http1;
 +*outlen = (unsigned char)strlen(alpn_http1);
 +return SSL_TLSEXT_ERR_OK;
  }
 
  /* Now select the most preferred protocol from the proposals. */



Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Rainer Jung

Hi Stefan,

Am 01.04.2015 um 18:22 schrieb Stefan Eissing:

Jim,

today I converted your commit to a path on 2.4.12 and tested it with mod_h2. 
All fine!

Then I got a trouble report that alpn negotiation always selected http/1.1 unless SSLAlpnPreference 
configured something else. This is due to the deterministic ordering and http/1.1.  
h2. So, I made a slight modification, attached below.


Maybe related but concerning NPN: There was a difference between the NPN 
parts of your original Bugzilla attachment and what was already in 
mod_ssl trunk and therefore was not applied. In your attachment, there 
was some code for sorting in ssl_callback_AdvertiseNextProtos() which 
IMHO does not exist in trunk. Is that part necessary?


A second difference: your original addition to ssl_engine_io.c had the 
NPN and the ALPN parts merged in the same code block. In trunk those are 
now two separate pieces coming after each other.



--- modules/ssl/ssl_engine_kernel.c 2015-04-01 15:23:48.0 +0200
+++ ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c 
2015-04-01 17:53:03.0 +0200
@@ -2177,7 +2152,7 @@
  }

  /*
- * Compare to ALPN protocol proposal. Result is similar to strcmp():
+ * Compare two ALPN protocol proposal. Result is similar to strcmp():
   * 0 gives same precedence, 0 means proto1 is prefered.
   */
  static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
@@ -2254,14 +2229,8 @@
  i += plen;
  }

-/* Regardless of installed hooks, the http/1.1 protocol is always
- * supported by us. Add it to the proposals if the client also
- * offers it. */
  proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
   sizeof(char *));
-if (ssl_array_index(client_protos, alpn_http1) = 0) {
-APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
-}

  if (sslconn-alpn_proposefns != NULL) {
  /* Invoke our alpn_propos_proto hooks, giving other modules a chance 
to
@@ -2280,9 +2249,16 @@
  }

  if (proposed_protos-nelts = 0) {
-ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
-  none of the client alpn protocols are supported);
-return SSL_TLSEXT_ERR_ALERT_FATAL;
+/* Regardless of installed hooks, the http/1.1 protocol is always
+ * supported by us. Choose it if none other matches. */
+if (ssl_array_index(client_protos, alpn_http1)  0) {
+ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
+  none of the client alpn protocols are supported);
+return SSL_TLSEXT_ERR_ALERT_FATAL;
+}
+*out = (const unsigned char*)alpn_http1;
+*outlen = (unsigned char)strlen(alpn_http1);
+return SSL_TLSEXT_ERR_OK;
  }

  /* Now select the most preferred protocol from the proposals. */


Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-04-01 Thread Jim Jagielski
Yeah, I agree. Right now, trunk pretty much uses

#ifdef HAVE_TLS_ALPN
blah blah
#endif
#ifdef HAVE_TLS_NPN
blah2 blah2
#endif

Instead of

#if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)

so that ripping out NPN would be easier. The question is
which to use for 2.4...

 On Apr 1, 2015, at 1:59 PM, Stefan Eissing stefan.eiss...@greenbytes.de 
 wrote:
 
 Well, I took the trunk version, diffed to 2.4.12 and made a patch for my 
 sandbox build (removed the non alpn/npn parts). That works for mod_h2 after 
 adding callbacks for the npn stuff. 
 
 I have no real pref to keep npn and alpn separate or not. my thought when 
 merging these was that npn will go away rather soon as alpn is supposed to 
 replace it and is afaik the cryptographically more secure way (i think npn is 
 prone to mitm downgrade attacks). 
 
 cheers,
  Stefan
 
 
 
 Am 01.04.2015 um 19:28 schrieb Jim Jagielski j...@jagunet.com:
 
 Yeah, there is some overlap which I'm trying to grok,
 since trunk had NPN but not ALPN, so I tried to have the
 ALPN stuff self-contained. But not sure if that's the best
 way since, for example, alpn_proposefns is adjusted
 in ssl_callback_AdvertiseNextProtos(), but that is a
 NPN only function in trunk, so it uses npn_proposefns.
 
 I'm thinking that in trunk we shouldn't think of
 NPN and ALPN as distinct.
 
 On Apr 1, 2015, at 12:47 PM, Rainer Jung rainer.j...@kippdata.de wrote:
 
 Hi Stefan,
 
 Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
 Jim,
 
 today I converted your commit to a path on 2.4.12 and tested it with 
 mod_h2. All fine!
 
 Then I got a trouble report that alpn negotiation always selected 
 http/1.1 unless SSLAlpnPreference configured something else. This is due 
 to the deterministic ordering and http/1.1.  h2. So, I made a slight 
 modification, attached below.
 
 Maybe related but concerning NPN: There was a difference between the NPN 
 parts of your original Bugzilla attachment and what was already in mod_ssl 
 trunk and therefore was not applied. In your attachment, there was some 
 code for sorting in ssl_callback_AdvertiseNextProtos() which IMHO does not 
 exist in trunk. Is that part necessary?
 
 A second difference: your original addition to ssl_engine_io.c had the NPN 
 and the ALPN parts merged in the same code block. In trunk those are now 
 two separate pieces coming after each other.
 
 --- modules/ssl/ssl_engine_kernel.c2015-04-01 15:23:48.0 +0200
 +++ 
 ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c
 2015-04-01 17:53:03.0 +0200
 @@ -2177,7 +2152,7 @@
 }
 
 /*
 - * Compare to ALPN protocol proposal. Result is similar to strcmp():
 + * Compare two ALPN protocol proposal. Result is similar to strcmp():
 * 0 gives same precedence, 0 means proto1 is prefered.
 */
 static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
 @@ -2254,14 +2229,8 @@
i += plen;
}
 
 -/* Regardless of installed hooks, the http/1.1 protocol is always
 - * supported by us. Add it to the proposals if the client also
 - * offers it. */
proposed_protos = apr_array_make(c-pool, client_protos-nelts+1,
 sizeof(char *));
 -if (ssl_array_index(client_protos, alpn_http1) = 0) {
 -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
 -}
 
if (sslconn-alpn_proposefns != NULL) {
/* Invoke our alpn_propos_proto hooks, giving other modules a 
 chance to
 @@ -2280,9 +2249,16 @@
}
 
if (proposed_protos-nelts = 0) {
 -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 -  none of the client alpn protocols are supported);
 -return SSL_TLSEXT_ERR_ALERT_FATAL;
 +/* Regardless of installed hooks, the http/1.1 protocol is always
 + * supported by us. Choose it if none other matches. */
 +if (ssl_array_index(client_protos, alpn_http1)  0) {
 +ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
 +  none of the client alpn protocols are 
 supported);
 +return SSL_TLSEXT_ERR_ALERT_FATAL;
 +}
 +*out = (const unsigned char*)alpn_http1;
 +*outlen = (unsigned char)strlen(alpn_http1);
 +return SSL_TLSEXT_ERR_OK;
}
 
/* Now select the most preferred protocol from the proposals. */
 



Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Jim Jagielski
Hmmm.. missed a patch.

r1670434
 On Mar 31, 2015, at 2:28 PM, Jim Jagielski j...@jagunet.com wrote:
 
 Hmmm... let me double check.
 
 On Mar 31, 2015, at 2:22 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 08:08 PM, Jim Jagielski wrote:
 They are used by mod_spdy and/or mod_h2..., iirc
 
 They use private structures of mod_ssl directly? That does not sound like a 
 good idea.
 
 Regards
 
 Rüdiger
 
 
 On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 07:12 PM, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
  httpd/httpd/trunk/modules/ssl/mod_ssl.c
  httpd/httpd/trunk/modules/ssl/mod_ssl.h
  httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
  httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
  httpd/httpd/trunk/modules/ssl/ssl_private.h
 
 
 I don't know if I miss the obvious, but where do we use
 
 ssl_alpn_pref
 alpn_proposefns
 
 ?
 
 I can only see that we set it, but I fail to see where it is used.
 
 Regards
 
 Rüdiger
 
 
 



Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Jim Jagielski
They are used by mod_spdy and/or mod_h2..., iirc

 On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 07:12 PM, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
httpd/httpd/trunk/modules/ssl/mod_ssl.c
httpd/httpd/trunk/modules/ssl/mod_ssl.h
httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
httpd/httpd/trunk/modules/ssl/ssl_private.h
 
 
 I don't know if I miss the obvious, but where do we use
 
 ssl_alpn_pref
 alpn_proposefns
 
 ?
 
 I can only see that we set it, but I fail to see where it is used.
 
 Regards
 
 Rüdiger



Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Ruediger Pluem


On 03/31/2015 07:12 PM, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/mod_ssl.h
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h


I don't know if I miss the obvious, but where do we use

ssl_alpn_pref
alpn_proposefns

?

I can only see that we set it, but I fail to see where it is used.

Regards

Rüdiger




Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Ruediger Pluem


On 03/31/2015 08:08 PM, Jim Jagielski wrote:
 They are used by mod_spdy and/or mod_h2..., iirc

They use private structures of mod_ssl directly? That does not sound like a 
good idea.

Regards

Rüdiger

 
 On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote:



 On 03/31/2015 07:12 PM, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397

 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set

 Modified:
httpd/httpd/trunk/modules/ssl/mod_ssl.c
httpd/httpd/trunk/modules/ssl/mod_ssl.h
httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
httpd/httpd/trunk/modules/ssl/ssl_private.h


 I don't know if I miss the obvious, but where do we use

 ssl_alpn_pref
 alpn_proposefns

 ?

 I can only see that we set it, but I fail to see where it is used.

 Regards

 Rüdiger
 
 


Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

2015-03-31 Thread Jim Jagielski
Hmmm... let me double check.

 On Mar 31, 2015, at 2:22 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 08:08 PM, Jim Jagielski wrote:
 They are used by mod_spdy and/or mod_h2..., iirc
 
 They use private structures of mod_ssl directly? That does not sound like a 
 good idea.
 
 Regards
 
 Rüdiger
 
 
 On Mar 31, 2015, at 1:57 PM, Ruediger Pluem rpl...@apache.org wrote:
 
 
 
 On 03/31/2015 07:12 PM, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
   httpd/httpd/trunk/modules/ssl/mod_ssl.c
   httpd/httpd/trunk/modules/ssl/mod_ssl.h
   httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
   httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
   httpd/httpd/trunk/modules/ssl/ssl_private.h
 
 
 I don't know if I miss the obvious, but where do we use
 
 ssl_alpn_pref
 alpn_proposefns
 
 ?
 
 I can only see that we set it, but I fail to see where it is used.
 
 Regards
 
 Rüdiger