Hello,
We're looking for a way to add some kind of cross-control between an application and the TLS tunnelling tool that protects the data. I'll give an example, that may be easier to understand.
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.
There is no way (or, rather, we have not found any way) to cross-check that the certificate AND the requested, application-level login, are linked together. This means that my evil neighbour, which bribed my gullible cat to get my login and password, could connect to my account (app-level auth) using his X509 cert (TLS tunnel auth).
We would like to perform this cross-check between X509 certificate AND application-level auth.
From our point of view, this means that we need to "extract and send" some
parts of the certificate (DN, validity dates, etc.) to some secondary tool/proxy. This one will check if the data is coherent wrt application credentials.
M. Henrik Riomar sent a patch (http://www.stunnel.org/pipermail/stunnel-users/2012-October/003909.html) on the list last october that is one step closer to what we are looking for. We could build from it.
Maybe some of you have already solved this kind of problem, or know of a tool that answer to this kind of needs ?
Tia,
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.
Hi, I'm quite late to your help request but, here I go :)
Assuming the frontend that checks the certificate is stunnel (otherwise I couldn't understand your explanation here)... I think you are missing the point there.
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.
Anyway I don't know how your scenario works but in my head there is this one:
- 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.
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?
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 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 your certificate, the password for your certificate and the password for the database app and he also uses the same client database app. (Not impossible but… well, you know)
I hope I cleared your doubts a little ;)
Regards.
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,
I see.
Then, you'll need several server services (ports so, too) in the stunnel configuration, each one allowing only one certificate matching with the one set locally and verify level 3.
Then, I can't help here. You'll need a separate app in the middle to allow only one username and password that could pass to the DB app if correct, as well as the rest of data traffic.
I understand now what you want but it's a bit hard, I think. Secure, but not easy :) But, well, that's security :)
It's my point of view. If anyone has solutions or ideas post them. We all will be interested too.
Regards.
Hello Javier,
On 02/02/13 22:40, Javier wrote:
Then, I can't help here. You'll need a separate app in the middle to allow only one username and password that could pass to the DB app if correct, as well as the rest of data traffic.
That's what we are working on : some small additions to stunnel, to (optionally) send some certificate-related data to the downlink application, and a protocol-aware relay downlink (in front of the real application). This relay will receive the certificate-related data and the stunnel-decrypted data flow, make its checks and let pass or drop everything.
Sincerely,
On Sun, 03 Feb 2013 19:54:06 +0100 Pierre-Yves Bonnetain py.bonnetain@ba-consultants.fr wrote:
Hello Javier,
On 02/02/13 22:40, Javier wrote:
Then, I can't help here. You'll need a separate app in the middle to allow only one username and password that could pass to the DB app if correct, as well as the rest of data traffic.
That's what we are working on : some small additions to stunnel, to (optionally) send some certificate-related data to the downlink application, and a protocol-aware relay downlink (in front of the real application). This relay will receive the certificate-related data and the stunnel-decrypted data flow, make its checks and let pass or drop everything.
Sincerely,
I see, but you don't need to send any certificate related data if you already have one relay app instance for each stunnel service. You only have to bother of find an application for relay.
I mean:
stunnel service 1 with level 3 verification only accepts user 1 certificate and relays data to relayer app instance 1 that only accepts user 1 user and password. stunnel service 2 with level 3 verification only accepts user 2 certificate and relays data to relayer app instance 2 that only accepts user 2 user and password.
As long as stunnel won't accept more certificates for each service than the one set to verify and the app behind each service only accepts that certificate user username and password, all is done, no other user can use that stunnel service unless knows every login data that is personalized for that user.
I think that now there is a closest approach to link certificate access and user/pass access without need to pass certificate data to other application.
But I have to admit that for me would be enough, but understanding your case, won't be for you, so I only can wish you to find the solution :) With my knowledge I couldn't do better...
I hope you can find what you need :)
Regards.
-
Javier -
Pierre-Yves Bonnetain