aspose file tools*
The moose likes Security and the fly likes Basic Authenication with SSL? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Basic Authenication with SSL?" Watch "Basic Authenication with SSL?" New topic
Author

Basic Authenication with SSL?

Luke Murphy
Ranch Hand

Joined: May 12, 2010
Posts: 300
Hi,
My understanding there are (at least) two ways you can secure connections to Java Web Architectures:

1.
Configure basic authentication in the web.xml and then add
that the transport guarentee os confidential as a user data constraint.

This will mean the traffic will all go over https on the https port.

2.
Use a cert. Distribute it to your clients and go that way.

What are the pro's and con's of both approaches?
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Hi Luke,

what exactly do you mean by "secure connections"? Authentication, authorization and encryption are often used in combination but they are neither the same things nor is it necessary to combine all these things depending on you requirements.

For example it's one thing to use HTTP basic authentication to "proof" a user's identity but it's not necessary (though surely reasonable) to secure the data with a confidential transport mechanism like SSL.

To your question regarding certificates: X.509 certificates (the typical certificates used for HTTPS web sites) can be used for different things. Most of the time certificates are only used to proof the authenticity of a web server and to encrypt the data between a browser and web server. But they also offer the possibility to use client certificates to authenticate clients (without having to enter a username and password or similar).

An additonal hint: It's difficult to tell if certificates are better than basic authentication or vice versa. But maybe a few thoughts may help you to make a decision depending on your needs.

The advantage of basic authentication is that you don't have to worry about distribution of the username/password that much. Of course the password has to get to the user in some way but that is easier than to provide a ceritifacte file I guess. The biggest disadvantage is probably that HTTP is a cleartext protocol by design. So it would be easy for a hacker to get user passwords with an ordinary network sniffer if you would only use plain HTTP. Therefore most (serious) web sites which use basic authentication or username/password based authentication additionally have to use HTTP + TLS/SSL = HTTPS to secure the data (i.e. username and password) transmitted between client and server. Another security issue is that there obviously is a password. As you often have to enter the password again when you log into a web site it's easy for others to spot what you're typing on your keyboard or to use something like a keylogger (if they are really evil).

Certificate based authentication uses asymmetric crypthography to establish a symmetric key for the actual encryption (this is the transport guarantee) during handshakes between client and server. Additionally X.509 certs allwo to proof the identity of the server and client (the authentication part). In this way certs are more secure because there are simply no passwords involved together with all the disadvantages of passwords as I said above. The single biggest disadvantage in this case is surely the client certificate. Firstly you have to distribute the client side certifcates in a secure way to your client as they are basically the key to your whole system. Once they are on the client you have to take care that the certificate files stay secure and can't be misused by others by stealing the authenticity of another person via its certificate. Certificates could optionally be secured by passphrases but then you are back again to the password problems, although this helps to make a stolen certificate useless if you don't know the passphrase, too.

Marco
Luke Murphy
Ranch Hand

Joined: May 12, 2010
Posts: 300
Thanks for that in depth answer Marco.

I think the purpose of the certificate is so the user can be confident of the application they are sending data to is who they think it is.
The purpose of the user password is so the application can be confident that user is who they say they are.

Would you agree with this?

Secondly, providing basic (or form based authentication) with SSL means the user password is encrypted. This means it is harder for hacker to pretend to be the user. But a hacker could still pretend to be the application unless there is a certificate.

Would you agree with this?

I'm interested in your thoughts on this one.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

I think the purpose of the certificate is so the user can be confident of the application they are sending data to is who they think it is.

That's correct but it's not the only purpose of certificates. I know it's a little bit confusing :-) In summary certificates can be used for two different things: authentication and/or encryption and this can be used on the server side and the client side! It's just that client side certifcates are rarely used for the average web site because it would be very complicated when you had to provide certificates for all potential users. For an enterprise or intranet application with well-known users this could make sense though and it would make usernames and passwords superfluous.
Secondly, providing basic (or form based authentication) with SSL means the user password is encrypted. This means it is harder for hacker to pretend to be the user.

That's correct. The issue is the same for basic and form based authentication. And the security issue is prevented for both by using HTTPS. Of course SSL can't prevent anyone from stealing your password on a post-it near your computer monitor
But a hacker could still pretend to be the application unless there is a certificate.

It depends. In general a hacker could even pretend to be your application with certificates. But there is another feature of certificates. They can be signed! And this is the only reason why secure web sites work in practice. There are official authorized companys (like VeriSign, Thawte etc.) which are allowed to sign a (typically server side certificate) to make it trustworthy. All modern browsers know the root certificates of these companies and therefore don't complain when you access a secured web site which uses a server certificate signed by one of these companies. Because the browser knows them and trusts them. The certificates of these certification authorities are simply bundled with the browsers of all popular vendors.

In contrast you can easily create SSL certificates yourself (for example with OpenSSL) and you can also sign them yourself. But because your personal root certificate you used to sign your other personal certificate is unkown to any browser by default, the browser will complain with a warning because it can't establish a trust relationship for your self-signed certificate. That way you would be warned by you browser if an attacker would use a self-signed certifcate to pretend that he is you ;-) You can test this very easy by creating a certificate and configuring your web server or application server to use the certificates and provide SSL support.

Moreover it's not that easy to get an offically signed certificate from one of the said companies. Otherwise an attacker could simply buy one. Usually you have to provide some information to proof your identity. For example you should be the owner of a domain, if the domain belongs to a company you probably have to provide something that can proof that it's really your company etc. What exactly is necessary depends on the signing company and security class of the certificate you want to purchase.

Without this trust feature and the possibility to sign certificates it would be pretty annoying to use them. You would have to check the identity of each certificate via telephone or something like this the first time you access a secured web site because you couldn't be sure that the server certificate really belongs to the web site. That's the reason why the said companies above exist (and earn good money by signing certificates). Btw. you can have a look at your browser settings to see which root certifactes of which companies it knows! Depending on your browser you can usually list all known so-called root CAs somewhere in the settings or preferences dialog.

Marco
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Marco Ehrentreich wrote:

<snip/>

Certificate based authentication uses asymmetric crypthography to establish a symmetric key for the actual encryption (this is the transport guarantee) during handshakes between client and server. Additionally X.509 certs allwo to proof the identity of the server and client (the authentication part). In this way certs are more secure because there are simply no passwords involved together with all the disadvantages of passwords as I said above. The single biggest disadvantage in this case is surely the client certificate. Firstly you have to distribute the client side certifcates in a secure way to your client as they are basically the key to your whole system.

I disagree with this last sentence. In general, the client generates a key pair such as RSA together with a certificate request (CSR) which he submits to a Certificate Authority (CA) together with proof that he is who he says he is. Having verified that the client is who he says he is, the CA then returns a certificate (signed by the CA) containing the clients public key and identity. On receipt of this certificate the client imports it into his keystore or browser or whatever he is using.

When the client connects to a server using SSL/TLS that needs client authentication then he uses the certificate obtained from the CA together with his very very very private key to prove to the server he is who he says he is. The server is then free to accept the connection if he thinks the client should be allowed to connect.

The client and server exchange certificates as part of the SSL/TLS handshake. In general the server does not send the client's certificate to the client but for some Intranet applications it may be that a company has it's own CA and will only accept connections if the client presents a certificate signed by this CA.


Once they are on the client you have to take care that the certificate files stay secure and can't be misused by others by stealing the authenticity of another person via its certificate.


Sorry but this is just not true. The private key associated with the public key that is contained in the certificate must be kept very very very secret but the certificate can be distributed to anyone since it contains no secret information. Without the private key the certificate has no value and cannot be used in SSL/TLS communication.


<snip/>


Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Hi James,

sorry, you're completely right! Don't know what I was writing I had completely forgotten to mention that "the certificate" is in reality two parts - the private key and the public key/certificate information. Thanks for clarifying this!

For the distribution of a client certificate what I really had in mind (and should have written) is that you would have to take care for generating and distributing client side keys and certificates if your users aren't capable of doing this themselves. I guess it's too complicated for the average user to generate a private key and CSR, send the CSR to the CA, receive the certificate, know where to put it and take care for the security of the private key on his machine. That's surely the most important reason that client side certificates are not that widely used (at least not to my knowledge).
If you don't want your users to take care of this whole thing you probably will have to generate keys/certificates for them and take care that it somehow ends up on the client machines. That's what I really wanted to write but technically you're of course correct. The distribution of the certificate itself (i.e. without the private key part) is of course not an issue. After all that's the reason for public key crypthography.

Next time I will take some more time to think before writing...

@Luke: Sorry for confusing you with partially wrong and incomplete information!

Marco
Luke Murphy
Ranch Hand

Joined: May 12, 2010
Posts: 300
Good stuff. I owe you both a beer.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Marco Ehrentreich wrote:Hi James,

<snip/>

For the distribution of a client certificate what I really had in mind (and should have written) is that you would have to take care for generating and distributing client side keys and certificates if your users aren't capable of doing this themselves. I guess it's too complicated for the average user to generate a private key and CSR, send the CSR to the CA, receive the certificate, know where to put it and take care for the security of the private key on his machine. That's surely the most important reason that client side certificates are not that widely used (at least not to my knowledge).
If you don't want your users to take care of this whole thing you probably will have to generate keys/certificates for them and take care that it somehow ends up on the client machines. crypthography.

<snip/>



Generating the keys for the client and distributing them to him is most definitely not a secure option! The client would be able to plausibly deny making any transactions since he is not the only person with access to the private key. To be secure the private key should only ever be available to the client! I say again - to be secure the private key should only ever be available to the client!

It is relatively straight forwards to write a program that running on the client's computer will securely generate the key pair, submit a CSR to a CA associated with the server, read the signed certificate from the CA and install it in a keystore on the clients computer that also contains the private key. The only difficulty is in authentication the client in the first place but this is the same as authenticating anyone who registers with a site.

Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

To be secure the private key should only ever be available to the client! I say again - to be secure the private key should only ever be available to the client!

Yes, yes and yes. Don't get me wrong, I never wanted to give the advice that you should distribute key/certificate pairs in an unsecure way. And of course it's a very good idea that noone but the owner owns the private key. I JUST wanted to say that it's not that easy to get a secure communication channel up and running with certificate based authentication and encryption in the first place IN CONTRAST TO username/password authentication like HTTP basic authentication or form based authentication. And of course you're right, it's no rocket science to give your clients a tool at hand which makes it easier for them to solve the initial difficulties with generating keys and certificates etc.

I think that Luke already got the point of this discussion!

Marco
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Basic Authenication with SSL?