Nick Kew <[EMAIL PROTECTED]>wrote:
...
It might be worth a --with-SNI configuration option, which
would label it as an experimental feature.
I imagine the use of SNI would need to be configured in
httpd.conf anyway, in the virtual host parts.
Would an overall directive like:
PermitVh
>> I managed to find some time to experiment with this patch against
>> 2.2.9, and so far so good. It works as advertised. I'm eager to see
>> SNI included in Apache!
+1,000,000 votes from LAMPs people.
-1,000 votes from phishers ... they don't want TLS to get easier to
use, because more certi
> As we all know, this will not be in 2.2.10... Please recall that
> things must be in -trunk before being viable for backport to 2.2.x.
It's impossible to even express how disappointing this is ;(
There are only two changes in TLS on the server side that have been
identified to have any effect
[EMAIL PROTECTED] wrote:
>
> From:
> "Eric Covener" <[EMAIL PROTECTED]>
> On Thu, Oct 9, 2008 at 5:59 AM, Ian G <[EMAIL PROTECTED]> wrote:
>>
>>> As we all know, this will
2008 18:51:14 +0100
From: G at mozo
To: Ian G <[EMAIL PROTECTED]>
Ian G wrote:
> I just saw today on the httpd maillist that TLS/SNI will *not* be in
> the next release of httpd.
Ian,
On 29th September, "Magamiako" changed the Wikipedia page on SNI to
claim that Apache 2
> Dr Stephen Henson <[EMAIL PROTECTED]> wrote:
> Ian G wrote:
>> But that it is now supported in OpenSSL (0.9.8 and beyond) ?
>>
>
> OpenSSL 0.9.9 (unreleased development version) has SNI support compiled
> in by default but that can be disabled.
>
> 0.9.
I'm not sure if any browser available currently support this, but I
suppose none. Maybe if it became RFC, you might get Mozilla folks
interested with this :)
As far as I know, Mozilla guys are hanging out for TLS/SNI, as is the
rest of the world. They and the other browsers have been ready f
According to the patch page, a reminder is good!
Superficially, it is easy to think of SNI as a feature enhancement.
Instead, it is better to think of it as a security bug fix to SSL, at
the protocol level.
The most common failure mode of any security system is that it is not
used. Turned o
Jonath writes: "As a browser, we do some things to help our users here,
but we can’t solve the problem. https resists this kind of surveillance
and tampering well, but requires sites to provide 100% of their content
over SSL."
http://blog.johnath.com/2009/03/05/deep-packet-inspection-consider
Ruediger Pluem wrote:
Name based virtual hosting with SSL does *only* work with SNI *enabled*
clients. Not SNI enabled clients receive a 403 when contacting any of
the name based virtual hosts (which enables you to set a nice error
page to explain to the user what happened and which browser to us
Hi all,
I've seen rumours that TLS/SNI is now shipped with some Apache HTTPDs.
But not been able to clarify. Can some kind soul correct me? False
hopes? Too early? Is it time to break out the champagne?
iang
[EMAIL PROTECTED] wrote:
SNI in 2.2.9? (Re: 2.2.9 status)
61495 by: Kaspar Brand
There are just a handful of useful patches in STATUS lacking
a single vote for inclusion in 2.2.9...
While not completely true for the SNI backport proposal (requires more
than a single additional vote)
Apologies in advance for the abrupt questions, point me at a
FAQ if you like.
I'm guessing that TLS/SNI ServerNameIndication failed to
make it into last week's release.
If so, do we have a timetable for the next release to aim for?
Are there any roadblocks to help clear to get it in?
iang
[EMAIL PROTECTED] wrote:
May I use this occasion to ask if there's still a chance of getting a
backport of SNI accepted for 2.2.x?
For me, +1. For the LAMPs guys, +1m. For the phishing
victims, +10m.
Ok, the numb
Paul wrote:
It is important enough, the problem is we don't want to a back port to
cause regression or other sidee effects, and to me that is the scariest
thing about the SNI patch(es).
There might be a compromise position here: As long as the
SNI patch causes no problem to other services, t
15 matches
Mail list logo
