On Mon, Nov 25, 2013 at 10:55 PM, William A. Rowe Jr.
wrote:
> It appears that our SNI hostname comparison is invalid for forward proxy
> applications, specifically proxy CONNECT. RFC 2616 states;
>
> 14.23 Host
>
> The Host request-header field specifies the Internet host and port
> number
On 26.11.2013 00:46, Yann Ylavic wrote:
>> Ideas for the appropriate patch to httpd? Scope this fix to CONNECT
>> requests alone, or all forward proxy requests?
>>
>>
> Maybe all forward proxy modules are concerned.
> There is PR
> 55782
> which I started to debug but did not finish (run out of t
On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand wrote:
> On 26.11.2013 00:46, Yann Ylavic wrote:
> >> Ideas for the appropriate patch to httpd? Scope this fix to CONNECT
> >> requests alone, or all forward proxy requests?
> >>
> >>
> > Maybe all forward proxy modules are concerned.
> > There is PR
On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic wrote:
> On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand wrote:
>
>> On 26.11.2013 00:46, Yann Ylavic wrote:
>> >> Ideas for the appropriate patch to httpd? Scope this fix to CONNECT
>> >> requests alone, or all forward proxy requests?
>> >>
>> >>
>> >
On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand wrote:
> On 26.11.2013 00:46, Yann Ylavic wrote:
> >> Ideas for the appropriate patch to httpd? Scope this fix to CONNECT
> >> requests alone, or all forward proxy requests?
> >>
> >>
> > Maybe all forward proxy modules are concerned.
> > There is PR
On 26.11.2013 09:29, Yann Ylavic wrote:
> Another point is that SNI can not be an IP address according to the RFC
> 6066 :
>
> 3. Server Name Indication
>[...]
>Literal IPv4 and IPv6 addresses are not permitted in "HostName".
>
> and this is not specifically checked by mod_proxy before f
On Tue, Nov 26, 2013 at 6:18 PM, Kaspar Brand wrote:
> On 26.11.2013 09:29, Yann Ylavic wrote:
> > Another point is that SNI can not be an IP address according to the RFC
> > 6066 :
> >
> > 3. Server Name Indication
> >[...]
> >Literal IPv4 and IPv6 addresses are not permitted in "HostNam
On 26.11.2013 10:38, Yann Ylavic wrote:
> With the per worker (single) connections-reslist model, If the connection
> were to be closed in determine_connection() when the Host mismatches, that
> would be be a painful performance penalty when SNI is enabled (no option to
> disable currently)...
Wit
On 26.11.2013 18:54, Yann Ylavic wrote:
> Do you know if the port can be part of the SNI (eg. "www.domain.net:8080")
> so that it can be checked against the Host (which may contain that port)? I
> can't find any reference about this.
Pure host names (FQDN!) only: RFC 6066, section 3.
Kaspar
On Tue, 26 Nov 2013 09:47:44 +0100
Yann Ylavic wrote:
> On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic
> wrote:
>
> > On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand
> > wrote:
> >
> >> On 26.11.2013 00:46, Yann Ylavic wrote:
> >> >> Ideas for the appropriate patch to httpd? Scope this fix to
> >>
On 12.12.2013 00:15, William A. Rowe Jr. wrote:
> The rest of the SNI hostname processing steps are where the problem
> lies. We still need to perform http headers -> vhost translation after
> the connection is established. If there's any desire to do SNI hostname
> validation, that has to be lim
> -Original Message-
> From: Kaspar Brand [mailto:httpd-dev.2...@velox.ch]
> Sent: Donnerstag, 12. Dezember 2013 07:01
> To: dev@httpd.apache.org
> Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
>
> On 12.12.2013 00:15, William A. Rowe Jr
On Thu, 12 Dec 2013 09:28:16 +
"Plüm, Rüdiger, Vodafone Group" wrote:
>
>
> > -Original Message-
> > From: Kaspar Brand [mailto:httpd-dev.2...@velox.ch]
> > Sent: Donnerstag, 12. Dezember 2013 07:01
> > To: dev@httpd.apache.org
> > Subj
On 12.12.2013 20:06, William A. Rowe Jr. wrote:
> On Thu, 12 Dec 2013 09:28:16 +
> "Plüm, Rüdiger, Vodafone Group" wrote:
>> The reason is that you can define SSL parameters in Virtual hosts
>> like SSLCiphers or SSLProtocols. If Host header and SNI host match
>> you can be sure that the param
On 13 Dec 2013, at 06:05, Kaspar Brand wrote:
> On 12.12.2013 20:06, William A. Rowe Jr. wrote:
>> On Thu, 12 Dec 2013 09:28:16 + "Plüm, Rüdiger, Vodafone Group"
>> wrote:
>>
>> Yes, and? Why would this differ from the historical handling of the Host:
>> header? The HTTP Host header is n
er 2013 07:01
>>> To: dev@httpd.apache.org
>>> Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT
>>> requests
>>>
>>> On 12.12.2013 00:15, William A. Rowe Jr. wrote:
>>>> The rest of the SNI hostname processing steps are wh
On Fri, Dec 13, 2013 at 10:46 AM, Ruediger Pluem wrote:
>
> William A. Rowe Jr. wrote:>
> > The SSL settings come from first the IP/port search, then the resolved
> > SNI hostname's vhost, and finally from the corresponding Host: named
> > vhost where applicable. Of course the Host: vhost config
On Fri, Dec 13, 2013 at 2:42 PM, Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:
>
>
>
>
> *Von:* Yann Ylavic [mailto:ylavic@gmail.com]
> *Gesendet:* Freitag, 13. Dezember 2013 13:09
> *An:* httpd
> *Betreff:* Re: Behavior of Host: vs.
On Fri, 13 Dec 2013 07:05:13 +0100
Kaspar Brand wrote:
> On 12.12.2013 20:06, William A. Rowe Jr. wrote:
> > On Thu, 12 Dec 2013 09:28:16 +
> > "Plüm, Rüdiger, Vodafone Group" wrote:
> >> The reason is that you can define SSL parameters in Virtual hosts
> >> like SSLCiphers or SSLProtocols.
On Fri, 13 Dec 2013 10:46:43 +0100
Ruediger Pluem wrote:
> William A. Rowe Jr. wrote:
> >
> > Yes, and? Why would this differ from the historical handling of the
> > Host: header? The HTTP Host header is not the dns name of this hop,
>
> It doesn't, but we clearly stated in the docs before: D
On 13.12.2013 15:52, Yann Ylavic wrote:
> I can't tell whether this applies to all the other SSL parameters though
> (most -if not all?- seem to be handled the same way in ssl_hook_Access(),
> but I didn't do an exhaustive search to tell the truth, and maybe it is not
> feasible here for all).
An
On 13.12.2013 20:17, William A. Rowe Jr. wrote:
> I will agree, plain-text forward proxy listeners are unaffected, only
> https:// listeners are tested for TLS/Host: mismatches. Also, if the
> proxy request refers to a resource on the same proxy host, I suppose
> that would also succeed. Although
On Sat, 14 Dec 2013 09:04:53 +0100
Kaspar Brand wrote:
> I won't defend the checks introduced with r757373 under all
> circumstances, but they are definitely not the cause for this
> purported defect.
I beg to differ. We are left with a question of whether you are
responsible to defend the curr
On 14.12.2013 09:36, William A. Rowe Jr. wrote:
> I beg to differ. We are left with a question of whether you are
> responsible to defend the current behavior, or whether I can simply
> rely on RFC2817 to document that you are wrong,
RFC 2817 is irrelevant in the context of https: URIs (see its a
On Sat, 14 Dec 2013 10:25:00 +0100
Kaspar Brand wrote:
> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
> ProxyPass is not involved in the SSL forward proxy case at all, as I
> already tried to point out.
Good, we've finally agreed. This entire thread has been on forward
proxy, so I'm glad you
On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand wrote:
>
>> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
>> ProxyPass is not involved in the SSL forward proxy case at all, as I
>> already tried to point out.
>
> Good, we've finally agreed.
On Sat, Dec 14, 2013 at 9:02 AM, Kaspar Brand wrote:
> On 13.12.2013 15:52, Yann Ylavic wrote:
> > I can't tell whether this applies to all the other SSL parameters though
> > (most -if not all?- seem to be handled the same way in ssl_hook_Access(),
> > but I didn't do an exhaustive search to tell
On Sat, 14 Dec 2013 10:25:00 +0100
Kaspar Brand wrote:
> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
> > I beg to differ. We are left with a question of whether you are
> > responsible to defend the current behavior, or whether I can simply
> > rely on RFC2817 to document that you are wrong,
On Mon, 16 Dec 2013 22:18:46 +0100
Rainer Jung wrote:
> On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> > On Sat, 14 Dec 2013 10:25:00 +0100
> > Kaspar Brand wrote:
> >
> >> Just unload mod_proxy_http and mod_ssl
> >> from the configuration, and you'll find that forward proxying
> >> https://
On Mon, 16 Dec 2013 22:29:39 -0600
"William A. Rowe Jr." wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand wrote:
>
> > On 14.12.2013 09:36, William A. Rowe Jr. wrote:
> > > I beg to differ. We are left with a question of whether you are
> > > responsible to defend the current behavio
On Tue, Dec 17, 2013 at 5:44 AM, William A. Rowe Jr.
wrote:
>
> On Mon, 16 Dec 2013 22:29:39 -0600
> "William A. Rowe Jr." wrote:
>
> > My defect is really very simple, Here's a request to proxy.example.com
> > created in order to tunnel an https connection to server.example.com;
> >
> >CONNE
On 16.12.2013 20:25, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand wrote:
>
>> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
>> ProxyPass is not involved in the SSL forward proxy case at all, as I
>> already tried to point out.
>
> Good, we've finally agreed.
On 17.12.2013 05:29, William A. Rowe Jr. wrote:
> On Sat, 14 Dec 2013 10:25:00 +0100
> Kaspar Brand wrote:
>
>> On 14.12.2013 09:36, William A. Rowe Jr. wrote:
>>> I beg to differ. We are left with a question of whether you are
>>> responsible to defend the current behavior, or whether I can sim
On 26.11.2013 06:31, Kaspar Brand wrote:
> As far as PR 55782 is concerned, the problem might be that
> proxy_util.c:ap_proxy_determine_connection() does not take Host: header
> differences into account when checking if an existing connection can be
> reused (not sure). With SNI this would have the
William A. Rowe Jr. wrote:
> On Fri, 13 Dec 2013 10:46:43 +0100
> Ruediger Pluem wrote:
>
>> William A. Rowe Jr. wrote:
>>>
>>> Yes, and? Why would this differ from the historical handling of the
>>> Host: header? The HTTP Host header is not the dns name of this hop,
>>
>> It doesn't, but we
Kaspar Brand wrote:
> If your goal is to make httpd compatible with Chrome's "Secure Web
> Proxy" or another other client doing CONNECT over SSL, that's fine, and
> I'm not opposed to it (a small change to ssl_hook_ReadReq [attached]
I guess a more general fix for this would be:
Index: ssl_eng
Ruediger Pluem wrote:
>
>
> Kaspar Brand wrote:
>
>> If your goal is to make httpd compatible with Chrome's "Secure Web
>> Proxy" or another other client doing CONNECT over SSL, that's fine, and
>> I'm not opposed to it (a small change to ssl_hook_ReadReq [attached]
>
> I guess a more general
On 21.12.2013 14:21, Ruediger Pluem wrote:
>> I guess a more general fix for this would be:
>
> No further comments / feedback? If not then I would commit the patch.
The change looks fine to me (for easier comparison/review,
a whitespace-change-ignoring version is attached).
What would probably
Kaspar Brand wrote:
> On 21.12.2013 14:21, Ruediger Pluem wrote:
>>> I guess a more general fix for this would be:
>>
>> No further comments / feedback? If not then I would commit the patch.
>
> The change looks fine to me (for easier comparison/review,
> a whitespace-change-ignoring version is
On Mon, Dec 23, 2013 at 9:49 PM, Ruediger Pluem wrote:
>
>
> Kaspar Brand wrote:
>> On 21.12.2013 14:21, Ruediger Pluem wrote:
I guess a more general fix for this would be:
>>>
>>> No further comments / feedback? If not then I would commit the patch.
>>
>> The change looks fine to me (for eas
On 24/12/2013 11:58, Yann Ylavic wrote:
>
> According to
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3c48592955.2090...@velox.ch%3E,
> the (great) analyse Kaspar made in 2008, the only parameters which
> won't be renegotiated are SSLCACertificateFile/Path and
> SSLCADNReques
On Tue, Dec 24, 2013 at 1:50 PM, Dr Stephen Henson <
shen...@opensslfoundation.com> wrote:
> On 24/12/2013 11:58, Yann Ylavic wrote:
> >
> > According to
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3c48592955.2090...@velox.ch%3E
> ,
> > the (great) analyse Kaspar made in 2008
Yann Ylavic wrote:
> On Mon, Dec 23, 2013 at 9:49 PM, Ruediger Pluem wrote:
>>
>>
>> Kaspar Brand wrote:
>>> On 21.12.2013 14:21, Ruediger Pluem wrote:
> I guess a more general fix for this would be:
No further comments / feedback? If not then I would commit the patch.
>>>
>>> The
Ruediger Pluem wrote:
>
>
> Kaspar Brand wrote:
>> On 21.12.2013 14:21, Ruediger Pluem wrote:
I guess a more general fix for this would be:
>>>
>>> No further comments / feedback? If not then I would commit the patch.
>>
>> The change looks fine to me (for easier comparison/review,
>> a wh
On 02/18/2014 08:14 AM, Pavel Matěja wrote:
> There is one big risk when someone uses reverse HTTPS proxy with ServerAlias.
>
> Let say you have on both - backend and proxy servers options:
> ServerName www.example.com
> ServerAlias example.com
>
> In old non-SNI days everything was working just
Hi,
you missed the possibility when client goes to numeric IP
(https://1.2.3.4/) in reverse proxy configuration.
In such case you don't have useable 1.a, 1.b, 2.b nor 2.c. so there
should be 2.d. ServerName.
In 3. you have to check backend CN against proxy VirualServer's
ServerName in such ca
On Thu, Feb 20, 2014 at 6:28 PM, Pavel Matěja wrote:
> Hi,
> you missed the possibility when client goes to numeric IP (https://1.2.3.4/)
> in reverse proxy configuration.
> In such case you don't have useable 1.a, 1.b, 2.b nor 2.c. so there should
> be 2.d. ServerName.
IMHO in this case you don'
Dne 20.2.2014 19:18, Yann Ylavic napsal(a):
On Thu, Feb 20, 2014 at 6:28 PM, Pavel Matěja wrote:
Hi,
you missed the possibility when client goes to numeric IP (https://1.2.3.4/)
in reverse proxy configuration.
In such case you don't have useable 1.a, 1.b, 2.b nor 2.c. so there should
be 2.d. Se
Maybe what you need is a new ProxyPreserveHost on/off/canon option so
that mod_proxy uses the ServerName to fill in the Host header (hence
the SNI and the "proxy-request-hostname" note checked later by mod_ssl
against the CN).
I may be misguided but I see some relation between UseCanonicalName
and
On Fri, Feb 21, 2014 at 12:52 AM, Yann Ylavic wrote:
> Maybe what you need is a new ProxyPreserveHost on/off/canon option so
> that mod_proxy uses the ServerName to fill in the Host header (hence
> the SNI and the "proxy-request-hostname" note checked later by mod_ssl
> against the CN).
>
> I may
On Thu, Feb 20, 2014 at 7:18 PM, Yann Ylavic wrote:
> On Thu, Feb 20, 2014 at 6:28 PM, Pavel Matěja wrote:
>> Currently there are two possible scenarios with SSLCheckProxyPeerName On and
>> numeric Host/URI:
>> 1) you will try to open new connection which will fail the CN check and
>> client gets
William A. Rowe Jr. wrote:
> I believe that Kaspar and Ruediger are still entirely at odds with my
> position, but this 'enhancement' should never have been unilaterally
> applied as it was to 2.2.26 and must be reverted (even as the feature
> is 'fixed' with corrections they have blessed), e.g.
On 21.02.2014 04:08, Yann Ylavic wrote:
> Similarly, a new "SSLProxyCheckPeerCN canon" option could be handled
> so that admins needing "ProxyPreserveHost on" could still forward the
> client's Host but check the backend's CN against ServerName.
It remains my humble opinion, that this behavior shou
Yann Ylavic wrote:
> There seem to be different questions in this thread regarding SNI.
> Maybe we can enumerate them first to see what's going on (at least I need to)
>
> 1. What should the client-provided SNI be checked against?
> 1.1. for server or proxy-reverse
> 1.2. for proxy-forward/CONNE
On Mon, Feb 24, 2014 at 10:05 AM, Ruediger Pluem wrote:
>
> Yann Ylavic wrote:
> > There seem to be different questions in this thread regarding SNI.
> > Maybe we can enumerate them first to see what's going on (at least I need
> > to)
> >
> > 1. What should the client-provided SNI be checked aga
On Mon, Feb 24, 2014 at 10:57 AM, Yann Ylavic wrote:
>>
>> This could be a worthwhile idea and I have seen your patch in bugzilla.
>> For ease of commenting I would like you to post it here such that inline
>> comments could
>> be made (I would have some).
>
> Here it is (thanks for looking into
I see, makes sense.
Thanks, I'll think about it if/when we agree on a commit.
On Mon, Feb 24, 2014 at 6:19 PM, William A. Rowe Jr. wrote:
> On Mon, Feb 24, 2014 at 10:57 AM, Yann Ylavic wrote:
>>>
>>> This could be a worthwhile idea and I have seen your patch in bugzilla.
>>> For ease of comment
Yann Ylavic wrote:
> On Mon, Feb 24, 2014 at 10:05 AM, Ruediger Pluem wrote:
>>
>> Yann Ylavic wrote:
>>> There seem to be different questions in this thread regarding SNI.
>>> Maybe we can enumerate them first to see what's going on (at least I need
>>> to)
>>>
>>> 1. What should the client-pr
On Wed, Feb 26, 2014 at 9:45 PM, Ruediger Pluem wrote:
>
>
> Yann Ylavic wrote:
> > On Mon, Feb 24, 2014 at 10:05 AM, Ruediger Pluem
> wrote:
> >>
> >> Yann Ylavic wrote:
> >>> There seem to be different questions in this thread regarding SNI.
> >>> Maybe we can enumerate them first to see what'
On Wed, Feb 26, 2014 at 2:45 PM, Ruediger Pluem claimed:
> Even if they use IP/Port based virtual hosting the SNI name and supplied host
> header should be consistent.
For all incoming forward proxy requests your statement is complete nonsense.
The Host: header consistently appears to reflect
On Mon, 25 Nov 2013 15:55:41 -0600
"William A. Rowe Jr." wrote:
> It appears that our SNI hostname comparison is invalid for forward
> proxy applications, specifically proxy CONNECT. RFC 2616 states;
>
> 14.23 Host
>
> The Host request-header field specifies the Internet host and port
>
Dne Út 17. prosince 2013 18:35:50, Kaspar Brand napsal(a):
> On 26.11.2013 06:31, Kaspar Brand wrote:
> > As far as PR 55782 is concerned, the problem might be that
> > proxy_util.c:ap_proxy_determine_connection() does not take Host: header
> > differences into account when checking if an existing
Dne Ãt 18. února 2014 10:16:15, Daniel Kahn Gillmor napsal(a):
> On 02/18/2014 08:14 AM, Pavel MatÄja wrote:
> > There is one big risk when someone uses reverse HTTPS proxy with
> > ServerAlias.
> >
> > Let say you have on both - backend and proxy servers options:
> > ServerName www.example.c
I believe that Kaspar and Ruediger are still entirely at odds with my
position, but this 'enhancement' should never have been unilaterally
applied as it was to 2.2.26 and must be reverted (even as the feature
is 'fixed' with corrections they have blessed), e.g. the comparison
must be constrained to
There seem to be different questions in this thread regarding SNI.
Maybe we can enumerate them first to see what's going on (at least I need to)
1. What should the client-provided SNI be checked against?
1.1. for server or proxy-reverse
1.2. for proxy-forward/CONNECT
Possibilities are :
1.a. Host
Dne Pá 21. února 2014 10:08:42, Yann Ylavic napsal(a):
> On Fri, Feb 21, 2014 at 12:52 AM, Yann Ylavic wrote:
> > Maybe what you need is a new ProxyPreserveHost on/off/canon option so
> > that mod_proxy uses the ServerName to fill in the Host header (hence
> > the SNI and the "proxy-request-hostna
On Fri, Feb 21, 2014 at 10:48 AM, Pavel Matěja wrote:
> Dne Pá 21. února 2014 10:08:42, Yann Ylavic napsal(a):
>> On Fri, Feb 21, 2014 at 12:52 AM, Yann Ylavic wrote:
>> > Maybe what you need is a new ProxyPreserveHost on/off/canon option so
>> > that mod_proxy uses the ServerName to fill in the
Dne Pá 21. února 2014 13:55:56, Yann Ylavic napsal(a):
> On Thu, Feb 20, 2014 at 7:18 PM, Yann Ylavic wrote:
> > On Thu, Feb 20, 2014 at 6:28 PM, Pavel Matěja wrote:
> >> Currently there are two possible scenarios with SSLCheckProxyPeerName On
> >> and numeric Host/URI:
> >> 1) you will try to op
Hi:
On 11/26/2013 06:18 PM, Kaspar Brand wrote:
On 26.11.2013 09:29, Yann Ylavic wrote:
Another point is that SNI can not be an IP address according to the RFC
6066 :
3. Server Name Indication
[...]
Literal IPv4 and IPv6 addresses are not permitted in "HostName".
and this is not spec
On Tue, 26 Nov 2013 18:47:39 +0100
Peter Sylvester wrote:
> Hi:
>
> On 11/26/2013 06:18 PM, Kaspar Brand wrote:
> > On 26.11.2013 09:29, Yann Ylavic wrote:
> >> Another point is that SNI can not be an IP address according to
> >> the RFC 6066 :
> >>
> >> 3. Server Name Indication
> >> [...]
On Thu, Dec 12, 2013 at 12:20 AM, William A. Rowe Jr.
wrote:
> On Tue, 26 Nov 2013 18:47:39 +0100
> Peter Sylvester wrote:
>
> > Hi:
> >
> > On 11/26/2013 06:18 PM, Kaspar Brand wrote:
> > > On 26.11.2013 09:29, Yann Ylavic wrote:
> > >> Another point is that SNI can not be an IP address accordin
On 12/12/2013 12:15 AM, William A. Rowe Jr. wrote:
On Tue, 26 Nov 2013 09:47:44 +0100
Yann Ylavic wrote:
On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic
wrote:
On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand
wrote:
On 26.11.2013 00:46, Yann Ylavic wrote:
Ideas for the appropriate patch to htt
On 12/12/2013 10:28 AM, Plüm, Rüdiger, Vodafone Group wrote:
-Original Message-
From: Kaspar Brand [mailto:httpd-dev.2...@velox.ch]
Sent: Donnerstag, 12. Dezember 2013 07:01
To: dev@httpd.apache.org
Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
On
On Thu, 12 Dec 2013 08:46:32 +0100
Peter Sylvester wrote:
> > The rest of the SNI hostname processing steps are where the problem
> > lies. We still need to perform http headers -> vhost translation
> > after the connection is established. If there's any desire to do
> > SNI hostname validation
Dne St 19. února 2014 21:09:10, William A. Rowe Jr. napsal(a):
> I believe that Kaspar and Ruediger are still entirely at odds with my
> position, but this 'enhancement' should never have been unilaterally
> applied as it was to 2.2.26 and must be reverted (even as the feature
> is 'fixed' with cor
On Thu, Feb 20, 2014 at 7:47 AM, Pavel Matěja wrote:
> Dne St 19. února 2014 21:09:10, William A. Rowe Jr. napsal(a):
>> I believe that Kaspar and Ruediger are still entirely at odds with my
>> position, but this 'enhancement' should never have been unilaterally
>> applied as it was to 2.2.26 and
Dne Pá 21. února 2014 15:13:25, Pavel MatÄja napsal(a):
> Dne Pá 21. února 2014 13:55:56, Yann Ylavic napsal(a):
> > On Thu, Feb 20, 2014 at 7:18 PM, Yann Ylavic wrote:
> > > On Thu, Feb 20, 2014 at 6:28 PM, Pavel MatÄja wrote:
> > >> Currently there are two possible scenarios with SSLChe
Dne Čt 20. února 2014 08:13:13, Eric Covener napsal(a):
> On Thu, Feb 20, 2014 at 7:47 AM, Pavel Matěja wrote:
> > Dne St 19. února 2014 21:09:10, William A. Rowe Jr. napsal(a):
> >> I believe that Kaspar and Ruediger are still entirely at odds with my
> >> position, but this 'enhancement' should
mod_ssl won't fill in the SNI if it's an IP address, the check is not
in mod_proxy_http but in ssl_io_filter_connect() :
if (hostname_note &&
sc->proxy->protocol != SSL_PROTOCOL_SSLV2 &&
sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
apr_ipsubnet_create(&ip
>> Please post the full details in a bug report
> It's qute simple.
I meant the full details (config, logs, etc) in bugzilla.
https://issues.apache.org/bugzilla/
On 12/12/2013 12:20 AM, William A. Rowe Jr. wrote:
On Tue, 26 Nov 2013 18:47:39 +0100
Peter Sylvester wrote:
Hi:
On 11/26/2013 06:18 PM, Kaspar Brand wrote:
On 26.11.2013 09:29, Yann Ylavic wrote:
Another point is that SNI can not be an IP address according to
the RFC 6066 :
3. Server Nam
Dne Čt 20. února 2014 15:00:05, Yann Ylavic napsal(a):
> mod_ssl won't fill in the SNI if it's an IP address, the check is not
> in mod_proxy_http but in ssl_io_filter_connect() :
> if (hostname_note &&
> sc->proxy->protocol != SSL_PROTOCOL_SSLV2 &&
> sc->proxy->prot
82 matches
Mail list logo
