Hi Thierry,
On 3/05/12 00:34 AM, Thierry Moreau wrote:
Thanks for this info, very interesting to see deployment experience for
successful client PK key pairs.
PKP instead of PKI? Now you're talking. For my money, any serious
security has to replace PKI totally.
But the big assumption that a lot of business models start with is 1.
imagine the user has a browser....
With that, we're stuck with SSL/certs/medium security ... which one can
improve somewhat by going to client certs, but only a little as all the
other components are out of boundary, out of control.
...
This web server can have an immediate potential user base if it
negotiates the TLS session with a long list of CA distinguished names
(in the CertificateRequest message).
ah. In my work, I have discovered that it is far better to turn off
all decision making in the TLS/apache side, to simply set the cert
request to optional and pass the result in variables to the application.
SSLVerifyClient optional
SSLOptions +StdEnvVars +FakeBasicAuth +ExportCertData
SSLUserName SSL_CLIENT_S_DN_Email
Well, hum, I must confess something that might look like
"not-invented-here" syndrome, but I got rid of the apache server
altogether.
The system model is TLS-protected-web-server in an HSM (derived from the
web-server-in-embedded-system and the more classical HSM).
Security assurance is obtained by having
*only*the*required*software*logic* in the system boundary (e.g. not
losing sleep with protocol downgrade attacks).
Absolutely, I hear you. The reason I would not have done that is
because it is quite hard (say I) to do the whole server-side SSL & web
stack without using apache. It's a whole lotta work. Indeed, it's more
work than doing a custom protocol (I guess). So the notion is to use
httpd in dumb-pass-thru mode, and write the application code to manage
the security context (which you have to do anyway).
So the question is: how did you do the TLS/web stack in the HSM? How
compatible with browsers/certs/CAs/etc did you get it? Ok, no need to
answer if it is proprietary but it is an interesting idea.
There are other rationales/excuses for getting rid of apache, but they
are out of scope in this list.
Then, in the application code, read all the cert variables and make an
application level decision.
My application model is a little different. Mine is not a CA context,
and "all the cert variables" reduces to *only* the client public key.
Right. You're using TLS and certs as carriers for PKs only. Are you
even assuming a browser? If you're not, I'm wondering why you're using
any of the rest.
The management tools for the contemplated web server scheme would
include an issuer DN extraction utility from end-user or CA certificates
so that the list may be augmented based on casual observations. Also,
the SSL debugging tools will report the contents of CertificateRequest
messages from public servers supporting client certs.
Anyone went through such data collection before?
Well, to the extent above. My db has a table for all certs, and a
table for all users, with a join by cert identifiers between the two
tables.
As you may infer from the above, my join (or equivalent in the ID
management database schema) is on the client public key.
Nod. I should add that my project was within the context of a CA, so it
is as much an experiment in making the CA do CA-like things as anything.
Even more so than any perceived security benefits. Hence my focus on
reading the cert to extract "claims" and "rely" on those claims to the
extent that I can. Security problems? Surely, and I'm waiting to be
hit by them...
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
