I'm using the ClientCAs and ClientAuth options in tls.Config to do cert-based client authentication in my Go HTTP application. Is it possible to also verify the client certs against a provided CRL? I see in the x509 package there are some functions around CRLs, but I'm not sure how to configure the HTTP server to use them (ie. there doesn't seem to be any options in tls.Config that would cause a CRL to also be used).
Is it possible to also verify the client certs against a provided CRL?
Yes, it is possible, by means of the functionality provided in the crypto/x509 package (as you correctly stated in your question). However, higher-level interfaces such as crypto/tls.Config (consumed by net/http) do not offer that. A good chance to implement a check against a CRL probably is by inspecting net/http.Request.TLS.PeerCertificates.
A little bit of background: crypto/tls is maintained by security expert Adam Langley who has an opinion on revocation checking (original source is his blog). Though I have no evidence, one might assume that this was a deliberate design decision.
You can use VerifyPeerCertificate to validate connections against your CRL file. Simply iterate over your list of revoked certificates and check if the serial number of the revoked certs is equal to the peer certificiate's serial number.
Related
According to my understanding, when we are trying to connect to a website/url, even if one of the certificates in the SSL certificate chain of the website is present in the trust store then connection is established successfully. But, I want to establish a connection only if the domain level certificate is present in the trust store. And I am not allowed create a new trust store instead need to use the default trust store. How can this be implemented in Java? TIA.
Unfortunately for you, that's not how PKIs were designed to work. The search for any trusted root certificate in the chain is a design feature of PKIs that ensures we don't have to install a certificate per domain on clients - bloating local trust stores with millions of certificates and complicating revocation and renewal of certificates.
What you're looking for is referred to certificate pinning where the client validates that the certificate presented by the server has a specific thumbprint it knows and trusts before continuing any further communication with the server on the other end. It is essentially the client authenticating the server.
Depending on your particular implementation, the validation logic can be done in the application instead of at the TLS/SSL protocol layer, meaning you can do as much (CN, Key Usage Attributes, SAN) or as little (just thumbprint)validation as you want , but typically certificate thumbprints are used since they are *guaranteed to be unique. A interception proxy or other man-in-the-middle for instance can create a certificate with valid CN entry for your domain (valid domain validation), but they cannot spoof the thumbprint.
A certificate is a unique token issued to a particular individual. It is a form of identification, similar to a government-issued photo ID which most people carry.
Certificates were designed for one purpose - to convey an identity which can be verified as authentic. It does this via a chain of trust. If a client or server trusts the issuer of a certificate, then it will automatically trust the certificate.
Put in similar terms, this is similar to the TSA specifying guidelines for which forms of identification it will accept before it will let you into the security checkpoint. As long as you possess one of those valid forms of ID, the TSA will let you through. This is how the PKI is designed, and it has to be designed that way to function efficiently. So, there is no way to do this explicitly in the PKI framework.
What you're instead asking for is a separate level of identify verification beyond what PKI provides. A possible solution could be certificate pinning, but I'm not sure this gets you anywhere. If the private key is compromised, which is probably more likely than compromising a trusted CA, then you haven't gained any additional level of security.
Instead, best practice is to implement multi-factor authentication. Using the certificate itself as a second factor really doesn't make a whole lot of sense, because it isn't truly a two-factor identity. Instead, it would make more sense to use the PKI as-is, and establish a second authentication mechanism via TOTP or some other independent token generation.
i have a working ssl client authentication setup. is there a way to get the client certs fingerprint and put it in the request header when forwarding the request to another app?
according to:
http://httpd.apache.org/docs/current/mod/mod_ssl.html
there is nothing like:
RequestHeader set SSL_CLIENT_X_FINGERPRINT "%{SSL_CLIENT_X_FINGERPRINT}s"
any help appreciated
marcel
The closest thing you can do is to pass the whole certificate (SSL_CLIENT_CERT) and compute the fingerprint once it gets to your application.
Depending on how it's implemented, this shouldn't be too hard to do. For example, you could implement a Filter to do it in a Java servlet environment if needed: decode the PEM-encoded certificate to get it in DER form, pass the byte[] array you get to a MessageDigest initialised with the algorithm you require (and possibly hex-encode the result).
Note that "fingerprint" is a rather loose word. Most tools would use SHA-1 nowadays, but this hasn't necessarily always been the case (and this could change).
As a side-note, what you're trying to do suggests you're not using traditional PKI for authentication, but accepting potential self-signed certificates (or certificates signed by unknown CAs) and compare those fingerprints against a list you know. If this is the case, you're probably not interested so much in the "X.509 certificate" aspect of all this, but you're only using this certificate as a public key container (for which SSL/TLS would guarantee you the client has the matching private key), therefore you might find it more flexible to compare public keys, rather than certificates.
I'm adding SSL support (currently pushing forward with OpenSSL) to an existing application. I've never done anything with cryptology before and after reading numerous articles and watching videos I'm still a little confused as to how I can implement it for my specific situation.
Our software is client/server, and the end-user purchases both and will install it on their premises.
My first bit of confusion is regarding certificates and private keys, and how to manage these. Should I have one certificate that get installed along with the app? Should each end-user have their own certificate generated? What about private keys? Do I bake the private key into the server binary? Or should there be a file with the private key?
I'm sure this is a solved problem, but I'm not quite sure where to look, or what to search for.
Thanks for any help and advice.
Adding OpenSSL into existing app
If all you need is an example of a SSL/TLS client, have a look at the OpenSSL's wiki and TLS Client example.
My first bit of confusion is regarding certificates and private keys, and how to manage these.
Yes, key management and distribution is the hardest problem in crpyto.
Public CAs have legally binding documents covering these practices. They are called Certification Practice Statements (CPS). You can have a lot of fun with them because the company lawyers tell you what you don't want to hear (or the marketing department refuses to tell you).
For example, here's an excerpt from Apple Inc. Certification Authority Certification Practice Statement:
2.4.2. CA disclaimers of warranties
To the extent permitted by applicable law, Subscriber agreements,
if applicable, disclaim warranties from Apple, including any
warranty of merchantability or fitness for a particular purpose.
2.4.3. CA limitations of liability
To the extent permitted by applicable law, Subscriber agreements,
if applicable, shall limit liability on the part of Apple and shall
exclude liability for indirect, special, incidental, and
consequential damages.
So, Apple is selling you a product with no warranty and that offers no liability!!! And they want you to trust them and give them money... what a racket! And its not just Apple - other CAs have equally obscene CPS'es.
Should I have one certificate that get installed along with the app?
It depends. If you are running your own PKI (i.e., you are the CA and control the root certificate), then distribute your root X509 certificate with you application and nothing else. There's no need to trust any other CAs, like Verisign or Startcom.
If you are using someone else's PKI (or the Internet's PKI specified in RFC 5280), then distribute only the root X509 certificate needed to validate the chain. In this case, you will distribute one CA's root X509 certificate for validation. You could potentially trust just about any certificate signed by that particular CA, however (and its likely to be in the 10's of thousands if you are not careful).
If you don't know in advance, then you have to do like browsers and pick a bunch of CAs to trust and carry around their root certificates for your application. You can grab a list of them from Mozilla, for example. You could potentially trust just about any certificate signed by all CAs, however (and its likely to be in the 10's of millions if you are not careful).
There's a lot more to using public CAs like browsers, and you should read through Peter Gutmann's Engineering Security. Pay particular attention to the Security Diversification strategies.
When the client connects to your server, your server should send its X509 certificate (the leaf certificate) and any intermediate certificates required to build a valid chain back to the root certificate you distribute.
Finally, you can get free SSL/TLS certificates trusted by most major browsers (including mobile) from Eddy Nigg at Startcom. He charges for the revocation (if needed) because that's where the cost lies. Other CAs charge you up front and pocket the proceeds if not needed.
Should each end-user have their own certificate generated?
That is possible, too. That's called client certificates or client authentication authentication. Ideally, you would be running your own PKI because (1) you control everything (including the CA operations) and don't need to trust anyone outside the organization; and (2) it can get expensive to have a commercial CA sign every user's certificate.
If you don't want to use client side certificates, please look into PSK (Preshared Keys) and SRP (Secure Remote Password). Both beat the snot out of classic X509 using RSA key transport. PSK and SRP do so because they provide mutual authentication and channel binding. In these systems, both the client and server know the secret or password and the channel is setup up; or one (or both) does not know and channel setup fails. The plain text username and password are never put on the wire as in RSA transport and basic_auth schemes. (I prefer SRP because its based on Diffie-Hellman, and have implemented it in a few systems).
What about private keys?
Yes, you need to manage the private keys associated with certificates. You can (1) store them in the filesystem with permissions or ACLs; (2) store them in a Keystore or Keychain like Android, Mac OS X, iOS, or Windows; (3) store them in an Hardware Security Module (HSM); or (4) store them remotely while keeping them online using Key Management Interop Protocol (KMIP).
Note: unattended key storage on a server is a problem without a solution. See, for example, Peter Gutmann's Engineering Security, page 368 under "Wicked Hard Problems" and "Problems without Solutions".
Do I bake the private key into the server binary?
No. You generate them when needed and then store them with the best protection you can provide.
Or should there be a file with the private key?
Yes, something like that. See above.
I'm sure this is a solved problem, but I'm not quite sure where to look, or what to search for.
I'm not sure I would really call it solved because of the key distribution problem.
And some implementations are just really bad, so you would likely wonder how the code passed for production.
The first thing you probably want (since your focusing on key management) is a treatment of "key management" and "key hierarchies".
You might also want some reference material. From the security engineering point of view, read Gutmann's Engineering Security and Ross Anderson's Security Engineering. From an implementation standpoint, grab a copy of Network Security with OpenSSL and SSL and TLS: Designing and Building Secure Systems.
I have an OAuth2 api exposed that runs over HTTPS. Since OAuth2 relies on the security of HTTPS (doesn't do any of it's own signing) I added a note in the developer docs encouraging developers to make sure they validate the ssl certificate in their client applications.
I noticed that some apps make the crt file publicly available or include it in their client: https://github.com/stripe/stripe-ruby/tree/master/lib/data
I assume this is just to make sure it is using the right certs (and not any system installed ones)? If so, is it a good idea to make this crt file publicly available to developers on your API page and what is an easy command/way to generate this file?
Thanks!
When one makes the certificate public this way, he encourages clients to do binary comparison of certificates, i.e. validate the certificate not in a way defined by corresponding standards by building a certificate chain and validating them) but simply by comparing the presented certificate with the one stored in the client.
This method is broken in several ways:
binary comparison doesn't let the client know that the certificate was revoked
with binary comparison the change of server certificate would require updating all clients so that new certificate would be included there. Failure to upgrade would mean impossibility to connect.
Consequently inclusion of the certificate and "straightforward" use of such certificate makes no sense, neither for server owners nor for clients.
The only case when binary comparison is applicable is when self-signed certificates are used (in which case building and validating a chain won't work). But self-signed certificates is a bad idea in any case (due to reasons listed above and some other reasons).
What is the best means to verify that a server is who it says it is.
I'm guessing using signed SSL certs is the best route, but was wondering if there was any programmatic means to do this..
EDIT: This is for a an app where servers deal with other servers (authenticating each other) in order to exchange user info. (sorry if I forgot to mention that)
SSL certificates signed by an authorized CA (certificate authority) is the only way to be sure. Anything else can be faked, and especially any "programmatic means" would be particularly unreliable. Short and simple: an authorized SSL cert is the only thing a browser will recognize as reliable, regardless.
You don't need certificates to prove your identity (or a server's for that case) to someone. You can use pre-shared keys for that purpose, and avoid any public key infrastructure. The TLS (or SSL) protocol supports that. Find a TLS library that allows you to use TLS-PSK and use it.
I'd recommend HMAC or RSA. HMAC is pretty secure and much easier to implement. HMAC could get unwieldy if you have 5 servers that all need to communicate with each other directly.
What are you trying to secure? It sounds like a web application, and if it is one, then you should go with SSL certs.