Proposed: PKI Authentication for secure web access

2010-11-20 Thread Rob Lemaster
I would like to propose an enhancement to the Apache web server for
secure authentication.

If this is the wrong list, pls. reply with the correct list and I will
post it there.

SSH allows a user to create a public/private key pair and use that for
authentication. This is much more secure than simply using passwords
and adds the ability to add 'something you have' for multi-factor
authentication. I propose that the same functionality would be enabled
for web authentication.

This functionality would require support on the server and in the
client browser. The server would need to have the ability to store and
recognize a public keys for authentication. The client browser would
need to have the ability to create public/private keys and store them
securely. It would also need to have the ability to copy the keys to
other computers (home/work) or store them on a USB thumb drive for
remote access.

This functionality would be used primarily for web sites that require
secure authentication, such as banks, Ebay, and Paypal.

Do you think this is a good idea?


Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Arturo 'Buanzo' Busleiman
Been there, done that:

http://wiki.buanzo.org (enigform and mod_openpgp)

Not x509, though.



On 11/20/10, Rob Lemaster rklemas...@gmail.com wrote:
 I would like to propose an enhancement to the Apache web server for
 secure authentication.

 If this is the wrong list, pls. reply with the correct list and I will
 post it there.

 SSH allows a user to create a public/private key pair and use that for
 authentication. This is much more secure than simply using passwords
 and adds the ability to add 'something you have' for multi-factor
 authentication. I propose that the same functionality would be enabled
 for web authentication.

 This functionality would require support on the server and in the
 client browser. The server would need to have the ability to store and
 recognize a public keys for authentication. The client browser would
 need to have the ability to create public/private keys and store them
 securely. It would also need to have the ability to copy the keys to
 other computers (home/work) or store them on a USB thumb drive for
 remote access.

 This functionality would be used primarily for web sites that require
 secure authentication, such as banks, Ebay, and Paypal.

 Do you think this is a good idea?



Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Graham Leggett

On 20 Nov 2010, at 10:27 AM, Rob Lemaster wrote:


SSH allows a user to create a public/private key pair and use that for
authentication. This is much more secure than simply using passwords
and adds the ability to add 'something you have' for multi-factor
authentication. I propose that the same functionality would be enabled
for web authentication.

This functionality would require support on the server and in the
client browser. The server would need to have the ability to store and
recognize a public keys for authentication. The client browser would
need to have the ability to create public/private keys and store them
securely. It would also need to have the ability to copy the keys to
other computers (home/work) or store them on a USB thumb drive for
remote access.

This functionality would be used primarily for web sites that require
secure authentication, such as banks, Ebay, and Paypal.

Do you think this is a good idea?


Is there anything here that isn't already done by X509 client  
certificates, as offered by mod_ssl?


Regards,
Graham
--



Re: mod_disk_cache - mod_cache_disk

2010-11-20 Thread Graham Leggett

On 14 Oct 2010, at 8:50 PM, Ruediger Pluem wrote:


The naming of mod_disk_cache currently goes against the naming
convention of other grouped modules in the server, such as  
mod_proxy_*,

and mod_socache_*.

Are there any objections to me renaming mod_disk_cache to  
mod_cache_disk

for httpd v2.4?


+1


I am about to go ahead and change this, would it be possible for  
people doing builds for other than unix to check whether I've made the  
updates correctly?


Regards,
Graham
--



Re: mod_ssl's proxy support: make it per directory

2010-11-20 Thread Daniel Ruggeri


On 11/19/2010 9:13 AM, Graham Leggett wrote:

On 19 Nov 2010, at 3:15 PM, Plüm, Rüdiger, VF-Group wrote:


For a while, mod_ssl has been able to secure connections from
mod_proxy, backwards towards some backend server.

For some reason however, the directives that control this behavior
SSLProxy* are all scoped virtual host only, making it
possible to SSL
protect just one single ProxyPass going backwards, and not more than
one, something that severely limits the usefulness of the feature.


What limits do you see with the actual per virtual host configuration?


Most specifically, any attempt to set a client certificate to a
particular proxypass ends up being valid server wide.

Each backend server which a reverse proxy proxies to has the potential
to have different requirements for SSL, from client certs, to ciphers
used, etc.

We have worked around this to date by either delegating this task to
load balancers, or writing little php apps to proxy the connections, but
this is really ugly, when mod_proxy+mod_ssl can potentially do this itself.

Regards,
Graham
--



Indeed - this is a long standing limitation available in quite a few 
reverse proxies out there... and even several third party proxy modules 
for httpd.


--
Daniel Ruggeri



Re: mod_include: include virtual and error handling

2010-11-20 Thread Graham Leggett

On 02 Nov 2010, at 10:34 PM, Nick Kew wrote:


The lack of this one feature is the most cited reason I've been given
for why people have moved away from mod_include as a template
processor to other template processors within other servers. Rather
than moving to an entirely new type of server, I'd rather we just fix
the core problem.


Wouldn't the same argument support an onerror=url clause too?

Yes, you can use an errordocument.  But there seem to be a lot of
users who find that a difficult concept to grasp (an error document
that we intentionally use???), so it's not really a great answer.
Besides, an errordocument could easily end up getting overloaded!

The implementation should presumably be straightforward alongside
what you propose, and could use an errordocument processing path.


+1.

Turns out they would both work a very similar way.

Regards,
Graham
--



Re: Fwd: [us...@httpd] SSLRequire UTF-8 characters

2010-11-20 Thread Stefan Fritsch

On Fri, 19 Nov 2010, Joe Orton wrote:


On Fri, Nov 19, 2010 at 07:13:01AM +0100, Kaspar Brand wrote:

On 17.11.2010 15:53, Igor Galić wrote:

it might be appropriate to ping dev@ with this problem
I'm not sure if it's a bug or a feature.


I'd call it a missing feature... the problem is that mod_ssl treats all
values of any DN attribute (subject or issuer) as a sequence of 8-bit
characters.


Worth noting that the handling of SSL_*_S_DN is different to the
handling of the individual attributes, SSL_*_S_DN_* - the _DN string is
rendered as an escaped string whereas the attributes are exported as a
sequence of raw bytes.  That is all kind of messy (not to mention
undocumented)...


- Myles Bunbury (Myles) myles.bunb...@alcatel-lucent.com wrote:
After some investigation, I discovered that this line does successfully pick up 
the certificate:
SSLRequire (%{SSL_CLIENT_S_DN} =~ m#^/.*CN= \\x1C\\x00W\\x00e\\x00i\\x00r\\x00d 
\\x1d\\...@\\x00\\xbf\\x063\\x01\\xfd \\xAC\\x00.\\x00c\\x00o\\x00m.*$#i)


We could support this better by having a new set of exports:

  SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)?

(or something similarly named)

which works the same as _DN_ but exports the attributes as a UTF-8 byte
seequence regardless of the underlying ASN.1 type; this would be a
relatively simple hack.


Or have a (per vhost) directive that enables conversion for all 
SSL_*_S_DN_* and SSL_*_S_DN to UTF8. IMHO, this could even be enabled by 
default in 2.4.

Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Rob Lemaster
Isn't mod_ssl used solely for HTTPS (browser-server encryption)? I
would like to use PKI for user authentication like you can in SSH on
top of the encryption provided by HTTPS. The most secure option I see
available for web authentication currently is OTP tokens (RSA,etc)
that only work on one web site.

thanks,
-rob

On Sat, Nov 20, 2010 at 5:37 AM, Graham Leggett minf...@sharp.fm wrote:

 Is there anything here that isn't already done by X509 client certificates,
 as offered by mod_ssl?

 Regards,
 Graham


Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Issac Goldstand
On 20/11/2010 22:19, Rob Lemaster wrote:
 Isn't mod_ssl used solely for HTTPS (browser-server encryption)? I
 would like to use PKI for user authentication like you can in SSH on
 top of the encryption provided by HTTPS. The most secure option I see
 available for web authentication currently is OTP tokens (RSA,etc)
 that only work on one web site.

 thanks,
 -rob

Nope, you have full x509 based authentication out-of-the-box.  See
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients

  Issac


Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Rob Lemaster
Thanks for the link Issac. If this is already in Apache, why isn't
everyone using it?


On Sat, Nov 20, 2010 at 12:32 PM, Issac Goldstand mar...@beamartyr.net wrote:

 Nope, you have full x509 based authentication out-of-the-box.  See
 http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients

  Issac



Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Graham Leggett

On 20 Nov 2010, at 10:19 PM, Rob Lemaster wrote:


Isn't mod_ssl used solely for HTTPS (browser-server encryption)? I
would like to use PKI for user authentication like you can in SSH on
top of the encryption provided by HTTPS. The most secure option I see
available for web authentication currently is OTP tokens (RSA,etc)
that only work on one web site.


mod_ssl is used solely for https, yes, but the feature you're looking  
for is built into https by default already.


Certificates work symmetrically, both sides have the power to require  
the other side to present a valid certificate.


In the case you might be most familiar with, only one side has a  
certificate (the server). The other side (the browser) has no  
certificate. In this scenario, the browser can be sure it is speaking  
to the right server, because the server presented a signed  
certificate, but the server has no idea about the browser. Usually,  
some other authentication mechanism is used to identify the browser,  
of varying strengths (passwords, etc).


In the case you want however, both sides of the connection are  
configured to require a certificate from the other side. The  
certificates do the same job as the keys that are exchanged in your  
SSH configuration, they allow the other side to say yup, I trust  
you, and that trust works both ways.


Unlike an SSH key however, a certificate contains embedded within it  
details of the person (or thing) that owns the certificate, but these  
are details as far as the protocol is concerned.


Regards,
Graham
--



Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Rob Lemaster
Thanks for that explanation Graham!

I wasn't thinking in terms of CA-signed certificates like you and
Issac pointed out, but more of a PGP-type model, where I could use my
own self-signed public/private key pair created in Firefox  to
authenticate to many web sites. I realize that self-signed certs
aren't as secure (from the server's point of view), but I could
authenticate and answer pre-assigned secret questions before uploading
my public key to confirm my identity before the server accepts it. I'd
still be grateful for the additional security of CA-signed certs if my
bank and Paypal would use them..

-rob

On Sat, Nov 20, 2010 at 12:42 PM, Graham Leggett minf...@sharp.fm wrote:

 mod_ssl is used solely for https, yes, but the feature you're looking for is
 built into https by default already.

 Certificates work symmetrically, both sides have the power to require the
 other side to present a valid certificate.

 In the case you might be most familiar with, only one side has a certificate
 (the server). The other side (the browser) has no certificate. In this
 scenario, the browser can be sure it is speaking to the right server,
 because the server presented a signed certificate, but the server has no
 idea about the browser. Usually, some other authentication mechanism is used
 to identify the browser, of varying strengths (passwords, etc).

 In the case you want however, both sides of the connection are configured to
 require a certificate from the other side. The certificates do the same job
 as the keys that are exchanged in your SSH configuration, they allow the
 other side to say yup, I trust you, and that trust works both ways.

 Unlike an SSH key however, a certificate contains embedded within it details
 of the person (or thing) that owns the certificate, but these are details as
 far as the protocol is concerned.

 Regards,
 Graham
 --




Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Daniel Ruggeri


On 11/20/2010 2:39 PM, Rob Lemaster wrote:

Thanks for the link Issac. If this is already in Apache, why isn't
everyone using it?


On Sat, Nov 20, 2010 at 12:32 PM, Issac Goldstandmar...@beamartyr.net  wrote:


Nope, you have full x509 based authentication out-of-the-box.  See
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients

  Issac



For those who have a real security need to authenticate their clients in 
this way, and are willing to accept the hassles of this method, it is 
definitely used. However, the idea that a bank or paypal would issue 
certificates for each of its end users can get cumbersome very fast. 
See, the private key would be managed by the user. Users (and even some 
server administrators) are terribly poor at managing their private keys 
in a safe and secure fashion. Some potential complications are a user 
switching browsers, a user switching computers, a user's key becoming 
compromised, loss of the key, etc... On top of that, the signing 
institution would need to be able to keep track of certificates it 
should no longer accept via CRL's and have infrastructure ready to 
verify the cert is still valid.


Essentially, the logistics of getting END USERS to generate a key of 
appropriate size (and getting them to keep it safe), send a CSR, sign 
and return a certificate to them as well as the unavoidable technical 
support involved makes this an unattractive option to large institutions 
because the average Internet denizen isn't expected to know how to do 
this stuff The Right Way.


P.S.
IMHO, this conversation applies to PKI, X509 client authentication and 
even password authentication... all of these mechanisms boil down to the 
fact that there is some entity that knows who the user is and that your 
server will have to take a leap of faith at some point to trust that the 
user sitting at the keyboard is who they say they are.


--
Daniel Ruggeri



Removing passwords from the conf file

2010-11-20 Thread Daniel Ruggeri
In mod_ssl there is a very handy option of making an exec callout for 
SSLPassPhraseDialog rather than to put a password for your private key 
in the conf file. The obvious benefit here is that one can then design a 
solution to meet any arbitrary number of security challenges before 
allowing that password to be delivered.


One of my TODO patches is to add this same functionality in other 
places. The first that comes to mind (and something that has pestered me 
in the past) is AuthLDAPBindPassword (mod_authnz_ldap). Would anyone 
like to suggest other potential places this should be done before I put 
together a bug report and send in a patch?


P.S.
I am opposed to mod_ssl's check that the argument to SSLPassPhraseDialog 
exec:blah is a file. This prevents calling an arbitrary executable with 
parameters. Thoughts?


--
--
Daniel Ruggeri



Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Rob Lemaster
I understand your skepticism, but I am not advocating a complex CA
infrastructure and I have more faith in end users (possibly
misplaced). IMHO, it is reasonable for users to take that extra step
for their banking site or SSL-VPN. It's really not that big a deal to
generate a key pair in PuTTY, I can't imagine it would be that hard in
Firefox. The question about whether it will be immediately and
enthusiastically adopted by end users on their Facebook site is not
the point.

A bank or Paypal does not need to issue certificates. In fact, I
believe that self-signed keys like in the PGP model would be more
appropriate, because that key pair could be used for multiple sites. A
single key pair could be used in different browsers and computers, and
if they are lost, a new key pair could be generated and the old pair
revoked by the user just like in PGP. With self-signed keys, you don't
need to deal with CAs, CRLs, etc., which I agree would be too
burdensome.

Generating a key pair for SSH is pretty trivial, and using a wizard in
Firefox would simplify it enough to be accessible to just about
anyone.

Yes, authentication boils down to trust. This is the advantage of
using multi-factor authentication. You would then have something you
know (username and password) and something you have (private key).
This is required in the newer PCI  HIPAA requirements as well.


On Sat, Nov 20, 2010 at 1:57 PM, Daniel Ruggeri drugg...@primary.net wrote:

 For those who have a real security need to authenticate their clients in
 this way, and are willing to accept the hassles of this method, it is
 definitely used. However, the idea that a bank or paypal would issue
 certificates for each of its end users can get cumbersome very fast. See,
 the private key would be managed by the user. Users (and even some server
 administrators) are terribly poor at managing their private keys in a safe
 and secure fashion. Some potential complications are a user switching
 browsers, a user switching computers, a user's key becoming compromised,
 loss of the key, etc... On top of that, the signing institution would need
 to be able to keep track of certificates it should no longer accept via
 CRL's and have infrastructure ready to verify the cert is still valid.

 Essentially, the logistics of getting END USERS to generate a key of
 appropriate size (and getting them to keep it safe), send a CSR, sign and
 return a certificate to them as well as the unavoidable technical support
 involved makes this an unattractive option to large institutions because the
 average Internet denizen isn't expected to know how to do this stuff The
 Right Way.

 P.S.
 IMHO, this conversation applies to PKI, X509 client authentication and even
 password authentication... all of these mechanisms boil down to the fact
 that there is some entity that knows who the user is and that your server
 will have to take a leap of faith at some point to trust that the user
 sitting at the keyboard is who they say they are.

 --
 Daniel Ruggeri




Re: Proposed: PKI Authentication for secure web access

2010-11-20 Thread Sander Temme

On Nov 20, 2010, at 12:39 PM, Rob Lemaster wrote:

 Thanks for the link Issac. If this is already in Apache, why isn't
 everyone using it?

Because key management is just too freaking hard, and too much of a management 
and support burden.  

For God's sake, if we can't even get the Apache developer community to use PGP 
without handholding, how would you expect the general public to handle this 
tech? 

S.

 On Sat, Nov 20, 2010 at 12:32 PM, Issac Goldstand mar...@beamartyr.net 
 wrote:
 
 Nope, you have full x509 based authentication out-of-the-box.  See
 http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients
 
  Issac
 
 
 



-- 
Sander Temme
scte...@apache.org
PGP FP: FC5A 6FC6 2E25 2DFD 8007  EE23 9BB8 63B0 F51B B88A

View my availability: http://tungle.me/sctemme