Hello Javier,
On 25/01/13 20:52, Javier wrote:
On Tue, 15 Jan 2013 14:16:55 +0100 "Pierre-Yves Bonnetain" py.bonnetain@ba-consultants.fr wrote:
My BigDatabase has it's login/password authentication process. Since my customers want to access the database through bad Internet, we set up a SSL/TLS frontend. Each customer has his own X509 certificate, with all proper bells and jingles in it. The frontend checks the certificate (CA sig, validity, revocation, etc.) and then, as it should, passes the unencrypted flow to the application.
[...]
Let me ask one thing. When you say you pass "the unencrypted flow to the application", do you mean you pass the flow to an unencrypted connection too? If so, it is a big mistake.
That's not what I meant. The 'unencrypted flow' is 'the encrypted flow that stunnel decrypted'. The application sits behind stunnel, and cannot be reached otherwise. Otherwise, as you wrote, it would be a hell of a big mistake.
- app with database can't accept direct internet connections
(important!!!!)
- stunnel needed in the client/user and in the server.
- user certificate created with password (so each time the user
open stunnel, it is requested by Stunnel to start)
- stunnel checks certificate against CA
- stunnel passes the flow to the app and this requests the
user/password
Here you have a double identification check.
No. We do not have a double identification. We have two un-correlated identifications : outer-level, with stunnel and the cert, and inner-level, by the application. Of course, they _should_ be related. But there is currently nothing to enforce this link.
You have an encrypted connection where is checked that there is a valid certificate and, therefore, a valid user; also you have an application that, after being checked the certificate, it checks for an user and password to be able to use it.
So, why do you need or why are you seeking for a check of a certificate by the application?
To prevent one legitimate user (with his own cert) to impersonate another user (application-wise).
Maybe I didn't explain before. The application can't accept a connection if there is not a valid connection with stunnel first, which requires a valid certificate. So, by insist in check the certificate?
I may use a valid certificate (mine) and connect to my neighbour's account (application-wise). Or try to brute-force the application's login. Or know that some blurry-eyed admin did not change the app's default admin password and abuse this.
Another example, more business-oriented way. BigApp is managed by a team of 5 people. Unfortunately, BigApp has only one admin-level account. So the password is shared (that's bad, but that's not the question here) between all 5 people, which connect through stunnel (with their own cert).
One of the team changes jobs in the same company. He keeps his cert, but his access to the admin-account of BigApp should be revoked. The proper way would be to change the account password but hey, we know how these things go. If there exists a check between the cert (outer-level auth) and the application-user requested (inner-level auth), it would be enough, all other things being equal, to break this link.
I had this kind of connection you are telling here with a HTTP server that requested a login too and I had as I explained. You can't login to the HTTP server unless you have a valid certificate for stunnel to check.
The link between both is obvious, unless your neighbour has stolen
No, the link is absolutely not obvious. As a matter of fact, there is no link except indirectly. If you have one connection per 15/30 secs, of course you can correlate the stunnel and application logs. But if you have a user base numbering in the tens of thousands, that's another problem altogether.
your certificate, the password for your certificate and the password for the database app and he also uses the same client database app.
Indeed, if Bad Guy as no valid certificate/privkey (either stolen as said above, or just his own), he cannot get past stunnel. But as soon as he has a valid cert, we get back to good old application-login stuff.
Sincerely,