Name based virtual host ssl clever solution

[Jeff Sadowski]

I think I just came up with a clever solution. However web browsers
will have to support srv records
the problem with virtual hosts is that you can have only one ssl
certificate per port (443)
because ssl requires it encrypted before it sends any other information.
A solution is to run a different key on different ports thus it could
distinguish via port what key to encrypt with
https://onedomain.com:443
https://twodomain.com:444

by default a web browser goes to port 443 for https
Now if a web browser followed the rules of svr records you could tell
the web browser to go to a different port using srv records

_https._tcp.onedomain.com SRV 443
_https._tcp.twodomain.com SRV 444

then again if the web browser follows SRV records it should
automatically go to the right port for ssl and you can have an ssl
connection to a virtual host each host with its own certificate.

[Patryk Szczygłowski]

On Sat, Nov 15, 2008 at 03:21, Jeff Sadowski <jeff.sadowski@...> wrote:

>
> I think I just came up with a clever solution. However web browsers
> will have to support srv records
> the problem with virtual hosts is that you can have only one ssl
> certificate per port (443)
> because ssl requires it encrypted before it sends any other information.
> A solution is to run a different key on different ports thus it could
> distinguish via port what key to encrypt with
> https://onedomain.com:443
> https://twodomain.com:444
>
> by default a web browser goes to port 443 for https
> Now if a web browser followed the rules of svr records you could tell
> the web browser to go to a different port using srv records
>
> _https._tcp.onedomain.com SRV 443
> _https._tcp.twodomain.com SRV 444
>
> then again if the web browser follows SRV records it should
> automatically go to the right port for ssl and you can have an ssl
> connection to a virtual host each host with its own certificate.

Yes, idea is good...

I've found several Internet Drafts about this topic, but none of them
got released as RFC so far:
http://tools.ietf.org/html/draft-andrews-http-srv-01
http://tools.ietf.org/html/draft-jennings-http-srv-00

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 :)

--
Patryk Szczygłowski
patryk.szczyglowski@...
JID/mail: patryk@...
P. J. O'Rourke  - "Never wear anything that panics the cat."

[Ian G-2]

> 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 for
ages.   There was a big push around 2005-2006 to get over to full TLS
because of SSLv2 bug and the emergence of phishing as an MITM.

TLS/SNI is the "real fix" for the bug, whereas other tricks (and there
are quite a few of them) are all suspect for one reason or another;
when you try them you discover what goes wrong.  There's a list of
possibilities here:

http://wiki.cacert.org/wiki/VhostTaskForce
http://en.wikipedia.org/wiki/Server_Name_Indication

TLS/SNI is working in Apache httpd, and has been for a while, but is
unreleased.  I don't know or understand the reason for that.



iang