You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Gregor Schneider <rc...@googlemail.com> on 2006/10/17 17:32:56 UTC
[users@httpd] Namebased Virtual Hosts
Hi guys,
I'm having the honor to set up an environment where 3 different virtual
hosts should be running on Apache 2.0.x, each listening on :80 and :443.
Operating system is Debian Sarge.
The problem: I'm just having ONE IP-adress. Since this is only a test- and
development-server, I thought I'd try the following trick:
- I updated the hosts from my Windows-machine with the host/IP-values: So
far, so good, host-names get resolved.
- I updated /etc/hosts from my Debian-machine - fine, host-names get
resolved.
- I updated ports.conf so that on both :80 and :443 there's a listener,
however, a netstat -ln looks awkward to me:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:896 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:8005 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8009 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8787 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:890 0.0.0.0:*
udp 0 0 0.0.0.0:893 0.0.0.0:*
I can see that on both ports there's a listener, but why is it
0.0.0.0instead of
127.0.0.1?
Anyhow, when I try to connect to either domain via :80 or :443 (ssl), I get
a "404 Not found", and I'm pretty sure that this is caused by a flaw in my
configs - but which one?
Below I'm posting my VirtualHosts-Def, maybe one of you could let me know
where the flaw is:
(Yes, rights are ok, paths are there, I've double-check that over and over
again).
Maybe one more interesting thing:
When restarting Apache2, I'm getting the following warning:
Starting web server: Apache2apache2: Could not determine the server's fully
qualified domain name, using 127.0.0.1 for ServerName
[Tue Oct 17 17:01:32 2006] [warn] NameVirtualHost test-ltc:80 has no
VirtualHosts
[Tue Oct 17 17:01:32 2006] [warn] NameVirtualHost test-ltc:443 has no
VirtualHosts
sites-availabe/dom (yes, I did "a2ensite" for each site and retarted Apache
after this):
NameVirtualHost test-dom:80
<VirtualHost test-dom:80>
ServerAdmin webmaster@localhost
ServerName test-dom
# don't loose time with IP address lookups
HostnameLookups Off
# needed for named virtual hosts
UseCanonicalName Off
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
ServerSignature Off
CustomLog /var/log/apache2/dom_access.log combined
ErrorLog /var/log/apache2/dom_error.log
DocumentRoot /var/www/dom
<Directory /var/www/dom>
Options FollowSymLinks
AllowOverride None
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order deny,allow
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Deny from all
</Directory>
</VirtualHost>
sites-available/dom-ssl:
NameVirtualHost test-dom:443
<VirtualHost test-dom:443>
ServerAdmin webmaster@localhost
ServerName test-dom
# don't loose time with IP address lookups
HostnameLookups Off
# needed for named virtual hosts
UseCanonicalName Off
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
ServerSignature Off
CustomLog /var/log/apache2/dom-ssl_access.log combined
ErrorLog /var/log/apache2/dom-ssl_error.log
# SSL
SSLEngine On
SSLCipherSuite HIGH:MEDIUM
SSLCertificateFile /etc/apache2/ssl/dom.crt
SSLCertificateKeyFile /etc/apache2/ssl/dom.key
DocumentRoot /var/www/ssl/dom
<Directory /var/www/ssl/dom>
Options FollowSymLinks
AllowOverride None
AuthName "DOM_Auth"
AuthType Cookie
CookieAuth on
CookieAuth_DBhost localhost
CookieAuth_DBName apacheSSO
CookieAuth_DBtable inter_sessions
CookieAuth_DBUser test
CookieAuth_DBPassword test
CookieAuth_UsernameField username
CookieAuth_SessnameField sessname
CookieAuth_SessvalField sesskey
CookieAuth_CookieName JSESSIONIDSSO
CookieAuth_ExpiryField expiry
# CookieAuth_RemoteIPField remoteip
CookieAuth_FailureURL /SingleSignOn
require valid-user
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order deny,allow
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Deny from all
</Directory>
</VirtualHost>
The other files (site2, site2-ssl, site3, site3-ssl) pretty much look the
same.
Any ideas?
Cheers
Greg
--
what's puzzlin' you, is the nature of my game
Re: [users@httpd] Namebased Virtual Hosts
Posted by Joshua Slive <jo...@slive.ca>.
On 10/17/06, Serge Dubrouski <se...@gmail.com> wrote:
> > The channel is encrypted, but you have no idea who encrypted it. It
> > could, for example, be a "man in the middle" that puts himself on the
> > wire between you and server, decrypts the original content,
>
> Tell me how would you do that without server's private key????? It
> doesn't matter who issued the certficate, encryption is always the
> same, based on a server's private key. So you have to steal it first.
The man-in-the-middle appears like any-old client to the server. If
you need this in more detail:
1. client makes request that it intends for server.
2. man-in-the-middle pretends to be server, negotiates encryption with
client, and accepts request.
3. man-in-the-middle pretends to be client, negotiations encryption
with server, and makes the request to server.
4. server sends response to man-in-the-middle, who decrypts it, saves
it, and re-encrypts it and resends to client. The server has no way
to verify the identity of the client, and the client can only verify
the identity of the server if it uses a proper certificate.
> The real problem with self signed certificates is that they don't
> guarantee that company A to which certificate was issued to us really
> company A and not something else. CA has to check all data that is put
> into certificate before issuing it. But on other hand browser now
> always contact CAs to verify certificates. Is OCSP enabled in your
> browser by default?
The only really important thing in the certificate is the hostname,
since that is the only thing that the typical user can easily verify
(by looking at the URL-bar of their browser). Everything else is
buried deep in browser menus and rarely gets used. So when I do
online-banking, I verify that I have an encrypted connection (without
any certificate warnings) and that the url-bar has the correct site.
Provided I am confident that I know the domain name of my bank, that
isn't too bad security-wise.
But if the server certificate is not right, you're screwed.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Namebased Virtual Hosts
Posted by Serge Dubrouski <se...@gmail.com>.
On 10/17/06, Joshua Slive <jo...@slive.ca> wrote:
> On 10/17/06, Serge Dubrouski <se...@gmail.com> wrote:
> > On 10/17/06, Joshua Slive <jo...@slive.ca> wrote:
> > > On 10/17/06, Gregor Schneider <rc...@googlemail.com> wrote:
>
> > > > > And in addition, your second and third ssl sites are not going to work
> > > > > properly. You can only have one ssl site on each IP-address/port
> > > > > combination because the SSL certificate is selected before the
> > > > > hostname is known.
> > > >
> > > > Well, what is going to happen if I do specify more than one SSL-site per
> > > > IP/port-pair? Do I just get the message that the cert is invalid (I could
> > > > pretty much live with that)?
> > >
> > > Yes, you will have an invalid cert. But note that SSL with an invalid
> > > cert is no more secure than ordinary HTTP. So this may be okay for
> > > testing, but it doesn't provide any real security.
> > >
> > > Joshua.
> > >
> >
> > Why?! Per my understanding the channel will be crypted anyway. Self
> > signed certificate is invalid from the browser point of view as well,
> > but it doesn't prevent crypting. Do I miss something?
>
> The channel is encrypted, but you have no idea who encrypted it. It
> could, for example, be a "man in the middle" that puts himself on the
> wire between you and server, decrypts the original content,
Tell me how would you do that without server's private key????? It
doesn't matter who issued the certficate, encryption is always the
same, based on a server's private key. So you have to steal it first.
> stores it
> for whatever nefarious purpose, and then re-encrypts it and sends it
> to you.
Again where do you get the right private key to encrypt data?
>Without a certificate that represents the server of origin,
> you have no way of telling where it came from. This attack is a
> little more work than passively eavesdropping on a plain HTTP
> connection, but it is very feasible.
The real problem with self signed certificates is that they don't
guarantee that company A to which certificate was issued to us really
company A and not something else. CA has to check all data that is put
into certificate before issuing it. But on other hand browser now
always contact CAs to verify certificates. Is OCSP enabled in your
browser by default?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Namebased Virtual Hosts
Posted by Joshua Slive <jo...@slive.ca>.
On 10/17/06, Serge Dubrouski <se...@gmail.com> wrote:
> That's another story and all of this is true. But I wouldn't say that
> "it is no more secure than ordinary HTTP". Anyway I've got what you
> meant. Thanks.
It's more secure than ordinary HTTP in the same sense that 'rot13'ing
your email is more secure than sending plain text. It makes the
attacker work a little harder but won't stop anyone who's serious.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Namebased Virtual Hosts
Posted by Serge Dubrouski <se...@gmail.com>.
On 10/17/06, Joshua Slive <jo...@slive.ca> wrote:
> On 10/17/06, Serge Dubrouski <se...@gmail.com> wrote:
> > On 10/17/06, Joshua Slive <jo...@slive.ca> wrote:
> > > On 10/17/06, Gregor Schneider <rc...@googlemail.com> wrote:
>
> > > > > And in addition, your second and third ssl sites are not going to work
> > > > > properly. You can only have one ssl site on each IP-address/port
> > > > > combination because the SSL certificate is selected before the
> > > > > hostname is known.
> > > >
> > > > Well, what is going to happen if I do specify more than one SSL-site per
> > > > IP/port-pair? Do I just get the message that the cert is invalid (I could
> > > > pretty much live with that)?
> > >
> > > Yes, you will have an invalid cert. But note that SSL with an invalid
> > > cert is no more secure than ordinary HTTP. So this may be okay for
> > > testing, but it doesn't provide any real security.
> > >
> > > Joshua.
> > >
> >
> > Why?! Per my understanding the channel will be crypted anyway. Self
> > signed certificate is invalid from the browser point of view as well,
> > but it doesn't prevent crypting. Do I miss something?
>
> The channel is encrypted, but you have no idea who encrypted it. It
> could, for example, be a "man in the middle" that puts himself on the
> wire between you and server, decrypts the original content, stores it
> for whatever nefarious purpose, and then re-encrypts it and sends it
> to you. Without a certificate that represents the server of origin,
> you have no way of telling where it came from. This attack is a
> little more work than passively eavesdropping on a plain HTTP
> connection, but it is very feasible.
>
> Punchline: untrusted certificate = insecure connection
>
> Joshua.
>
That's another story and all of this is true. But I wouldn't say that
"it is no more secure than ordinary HTTP". Anyway I've got what you
meant. Thanks.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Namebased Virtual Hosts
Posted by Joshua Slive <jo...@slive.ca>.
On 10/17/06, Serge Dubrouski <se...@gmail.com> wrote:
> On 10/17/06, Joshua Slive <jo...@slive.ca> wrote:
> > On 10/17/06, Gregor Schneider <rc...@googlemail.com> wrote:
> > > > And in addition, your second and third ssl sites are not going to work
> > > > properly. You can only have one ssl site on each IP-address/port
> > > > combination because the SSL certificate is selected before the
> > > > hostname is known.
> > >
> > > Well, what is going to happen if I do specify more than one SSL-site per
> > > IP/port-pair? Do I just get the message that the cert is invalid (I could
> > > pretty much live with that)?
> >
> > Yes, you will have an invalid cert. But note that SSL with an invalid
> > cert is no more secure than ordinary HTTP. So this may be okay for
> > testing, but it doesn't provide any real security.
> >
> > Joshua.
> >
>
> Why?! Per my understanding the channel will be crypted anyway. Self
> signed certificate is invalid from the browser point of view as well,
> but it doesn't prevent crypting. Do I miss something?
The channel is encrypted, but you have no idea who encrypted it. It
could, for example, be a "man in the middle" that puts himself on the
wire between you and server, decrypts the original content, stores it
for whatever nefarious purpose, and then re-encrypts it and sends it
to you. Without a certificate that represents the server of origin,
you have no way of telling where it came from. This attack is a
little more work than passively eavesdropping on a plain HTTP
connection, but it is very feasible.
Punchline: untrusted certificate = insecure connection
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Namebased Virtual Hosts
Posted by Serge Dubrouski <se...@gmail.com>.
On 10/17/06, Joshua Slive <jo...@slive.ca> wrote:
> On 10/17/06, Gregor Schneider <rc...@googlemail.com> wrote:
>
> > So what is the best practise to specify this NameVirtualHost-directive? In
> > any file which contains the VirtualHost-directive (meaning one will contain
> > it, the others not? Or in httpd.conf?)
>
> Makes no difference. I'd use httpd.conf. (Actually, I would put
> EVERYTHING in httpd.conf unless you have a really complex config. I
> don't see the point of a bunch of tiny config files.)
>
> >
> > > And in addition, your second and third ssl sites are not going to work
> > > properly. You can only have one ssl site on each IP-address/port
> > > combination because the SSL certificate is selected before the
> > > hostname is known.
> >
> > Well, what is going to happen if I do specify more than one SSL-site per
> > IP/port-pair? Do I just get the message that the cert is invalid (I could
> > pretty much live with that)?
>
> Yes, you will have an invalid cert. But note that SSL with an invalid
> cert is no more secure than ordinary HTTP. So this may be okay for
> testing, but it doesn't provide any real security.
>
> Joshua.
>
Why?! Per my understanding the channel will be crypted anyway. Self
signed certificate is invalid from the browser point of view as well,
but it doesn't prevent crypting. Do I miss something?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Namebased Virtual Hosts
Posted by Joshua Slive <jo...@slive.ca>.
On 10/17/06, Gregor Schneider <rc...@googlemail.com> wrote:
> So what is the best practise to specify this NameVirtualHost-directive? In
> any file which contains the VirtualHost-directive (meaning one will contain
> it, the others not? Or in httpd.conf?)
Makes no difference. I'd use httpd.conf. (Actually, I would put
EVERYTHING in httpd.conf unless you have a really complex config. I
don't see the point of a bunch of tiny config files.)
>
> > And in addition, your second and third ssl sites are not going to work
> > properly. You can only have one ssl site on each IP-address/port
> > combination because the SSL certificate is selected before the
> > hostname is known.
>
> Well, what is going to happen if I do specify more than one SSL-site per
> IP/port-pair? Do I just get the message that the cert is invalid (I could
> pretty much live with that)?
Yes, you will have an invalid cert. But note that SSL with an invalid
cert is no more secure than ordinary HTTP. So this may be okay for
testing, but it doesn't provide any real security.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Namebased Virtual Hosts
Posted by Gregor Schneider <rc...@googlemail.com>.
Hi Hoshua,
first, thanks for your explanations, however, I'm havin 2 questions:
On 10/17/06, Joshua Slive <jo...@slive.ca> wrote:
You need only one NameVirtualHost directive for each IP-address/port
> combination. And you should not use hostnames in NameVirtualHost or
> <VirtualHost>. In a simple case like yours, you should use
> NameVirtualHost *:80
So what is the best practise to specify this NameVirtualHost-directive? In
any file which contains the VirtualHost-directive (meaning one will contain
it, the others not? Or in httpd.conf?)
And in addition, your second and third ssl sites are not going to work
> properly. You can only have one ssl site on each IP-address/port
> combination because the SSL certificate is selected before the
> hostname is known.
Well, what is going to happen if I do specify more than one SSL-site per
IP/port-pair? Do I just get the message that the cert is invalid (I could
pretty much live with that)?
Cheers
Greg
--
what's puzzlin' you, is the nature of my game
Re: [users@httpd] Namebased Virtual Hosts
Posted by Joshua Slive <jo...@slive.ca>.
On 10/17/06, Gregor Schneider <rc...@googlemail.com> wrote:
> NameVirtualHost test-dom:80
> <VirtualHost test-dom:80>
I'm not sure where you found this example. Certainly not in the official docs:
http://httpd.apache.org/docs/2.2/vhosts/name-based.html#using
You need only one NameVirtualHost directive for each IP-address/port
combination. And you should not use hostnames in NameVirtualHost or
<VirtualHost>. In a simple case like yours, you should use
NameVirtualHost *:80
(once) and
<VirtualHost *:80>
for each virtual host. Then you have to make sure that what you are
typing in your browsers URL bar for the hostname exactly matches the
hostname specified in ServerName in each virtual host.
And in addition, your second and third ssl sites are not going to work
properly. You can only have one ssl site on each IP-address/port
combination because the SSL certificate is selected before the
hostname is known.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org