I'm not patching this in, it has not passed review for the 2.2.x branch.  (I am
unconvinced it is correct as-is and need to spend some time doing some testing) 

If and when it goes into 2.2.x it'll get into Fedora via updates.

I confirmed my suspicion that this is not yet ready for production, FWIW.

http://marc.info/?l=apache-httpd-dev&m=120887963712283&w=2

Thanks for looking into this Joe... I can see from your email to httpd-dev that
the feature is going to need more scrutiny.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The problem here is that the Priority is set to LOW and the Severity is set to LOW.  These are wrong.  Priority should be HIGHEST, Severity should be HIGHEST.

Severity first:  The number one most common of all security failures is to not use the security system.  Because of the bug in SSL (the certificate is assumed by the server) this means SSL can only be used for one certificate in production use on one IP#.  There are workarounds, but they are no good.  Then, this blockage means that the vast majority of websites use *no SSL* because it is too much trouble, and the knowledge does not share across all the other websites like vhosts do.

So SSL is not widely used;  it is an exception.  That means most of the LAMPs packages are unprotected, routinely.  The knowledge is not interesting, and the UI developers can't see the need.  The sum total of this is much broader than anything SSL has ever seen.  Lack of TLS/SNI is the most severe bug ever, by its ability to block most SSL usage.

Next, priority:  This could have been low, but in 2003 or thereabouts, phishing became a serious threat.  Phishing is a breach of the authentication in SSL and the browser UI.  Because there was so little SSL use, and because the browser vendors had basically turned off the UI security features over time, it was an easy breach.  Phishing losses are in the order of billions per year, concentrated in English speaking countries.

Anything that helps anti-phishing should be high priority.  More SSL helps because it raises the profile of authentication and makes it available to the million or so LAMPs developers.  Those developers will then work with it and get the rest of the infrastucture from "exceptional-SSL" to "routine-SSL".  UI developers will help anything that looks popular.  Plus many other things.  The task is to create a virtuous circle of attention, so that SSL can be used to deal with phishing.

I agree that this sounds like a good feature, although I am not in a position to judge how well it works or if there is any problematic side effect (I assume that it is safe enough to not allow easy use of stolen server certs on different sites).

Now I am not sure about the severity: isn't this just an alternative to using the cert extensions that allow multiple hostnames per cert? 

IMHO the main issue with SSL is, that most people don't care to get an official (as in CA cert shipped with the browser) CA signed cert and instead go with self-signed certs to start with. That educates customers to accept whatever cert you get from a server.

How does this help?

Responsible server admins will get a cert that covers all their server names anyways, wouldn't they?

What am I missing?

I don't think there is a stability problem for major sites that rely on SSL because they simply won't turn it on in the config file.  This is more for the small sites with one sysadm, a linux box, and 20 hosted sites for small businesses and friends and employer.  Grassroots.  These guys will turn it on and really don't care, as long as it works.

Alternatives include using cert extensions to include multiple hostnames per cert.  These don't scale well though because every time something changes, we have to change the entire cert, which isn't so practical.  It also means that each website owner has to "cooperate" as they are sharing a cert as if they are the same business.  (I use these in absence of TLS/SNI.)

Certainly people getting their certificate for each of their sites remains an issue, and is the other big but orthogonal thing that is holding back SSL.  CAs and browsers are working to make that easier.  I won't mention names because I have conflicts of interest there.  People not using a CA-signed cert is a completely separate issue, and controversial.  CAs have an incentive to make their product easier to use, etc.

Ian, this lobbying is off-topic for Fedora bugzilla and does little to improve the development process.  Every user thinks that their bug/RFE of choice should be highest priority and severity.

SNI will be supported by mod_ssl in the Fedora httpd package as and when it's supported upstream.  SNI will be supported upstream as and when 2.4 is released and/or the patch is reviewed and accepted for backport to 2.2.   The SNI patches require very careful review due to the interaction with mod_ssl's access control hooks, as the existing review I performed on this patch has shown.

Please, just be patient.

Joe, thanks for your reply;  I agree with the practical aspects, but not with the higher conclusions.

Point 1:  Sure, it is lobbying.  What other method is available?  bugzilla is a maintenance channel, it is only a channel for bugs & patches.  When only that "language" is accepted, there is no way to even see the vast wealth of information that is available from other perspectives, such as the 5 year debate on phishing causes and fixes.  SNI fixes a bug, the precise form of which is breaching Kherckhoffs' 6th principle (usability).  But "by agreement" it is kicked up to the architectural level, and claimed to be a feature enhancement, by all developers.  By this flip of perspective, hands are washed, "enhancements" are unimportant.

Once it has been so poorly classified, there is no other choice but to lobby.

> Every user thinks that their bug/RFE of choice should be highest priority and severity.

Well, sure.  Point 2:  Let's see if we can agree on something.  Do you believe that SSL in httpd is used firstly for authentication of websites?  (IOW the second purpose of transport encryption is less interesting if the authentication is breached.)

And, do you agree that phishing is because of a failure of authentication of websites?  (Not necessarily in SSL, but nearby to SSL, at the application level...)

So, if that is agreeable, we can probably also agree that _ease of use of SSL_ has an inverse correlation to phishing, because if SSL was used "properly" we wouldn't have this problem.  Ease of use goes up, phishing down?  (To restate Kerckhoffs' 6th.)

Even if the correlation is only 1%, that's enough to make this the most expensive problem ever seen in the lifetime of SSL.

> please, just be patient.

Point 3, last:  The victims of phishing are being told they are LOW priority and LOW severity.  What else matters, ahead of actual breaches?

Last point!

(In reply to comment #9)
> Point 1:  Sure, it is lobbying.  What other method is available? 

Contributing to the development community by doing patch review, testing, etc, rather than simply talking about how other people should spend their time.

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug report is still valid from my point of view - even it can't be fixed
and solved right now. Moving it forward to Rawhide and setting FutureFeature.

I believe this is slated for 2.2.12:

http://www.mail-archive.com/dev@httpd.apache.org/msg43766.html

httpd 2.2.12 is now released, including SNI support.
http://www.apache.org/dist/httpd/CHANGES_2.2.12

Please test the SNI support in the 2.2.13 builds:

f10: http://koji.fedoraproject.org/koji/buildinfo?buildID=128810
f11: http://koji.fedoraproject.org/koji/buildinfo?buildID=127702

and leave feedback either here, or at:

https://admin.fedoraproject.org/updates/F11/FEDORA-2009-8812
https://admin.fedoraproject.org/updates/httpd-2.2.13-1.fc10

httpd-2.2.13-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update httpd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8812

httpd-2.2.13-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.