I created the certificate authority server using Node.js and some cryptographic library supporting RSA sign, verification and generating X.509. When I added the certificate revocation feature with Online Certificate Status Protocol(OCSP), I thought of why I have to send a request and receive a response with OCSP because only what I want to know is not OCSP Request/Response object but just certificate status(Good or revoked.)
Does it make sense requesting not OCSP response object(.PEM or something else) but the certificate status value like HTTP status code(200: OK, 400: NOT FOUND)?
OCSP (Online Certificate Status Protocol) is a standard protocol to get the current status of a certificate ruled by RFC6960
The protocol defines the interchanged messages, including content, encoding, content-type and HTTP response codes.
If you want to build a general-purpose PKI it does not make sense to define your own protocol because no current client will use it (browsers, mobile devices, software tools, etc.), but expect you to have a standard OCSP service.
But if you are going to build your own client tools for an internal PKI it may be useful to have a very simple status query service (e.g 200 GOOD, 401 REVOKED, 404 UNKNOWN). But in that case do not call it OCSP
The reason OCSP responds with an object signed by the CA is so that relying parties know that the object and hence the certificate status is authentic.
If your new status service receives a query of "What is the status of certificate with serial number 123456789" and returns a simple HTTP response, the client will not be able to authenticate that response; making it very simple to carry out a substitution attack and place a 200 GOOD response when in fact the certificate's private key has been compromised and a 401 REVOKED should be sent.
You cannot fix that by responding over HTTPS as that will result in perpetual recursive status checking.
You could possibly use HTTPS if the status server's certificate is issued by a CA that doesn't use your protocol, instead using alternatives such as OCSP or a CRL distribution point. But that just makes the whole solution more complex instead of simplifying the status checking problem.
Related
Integrating one of my application with with SAML 2.0 single sign on. Using Okta provider for this. I came to the point where I receive base64 encoded "SAML response token" after successful authetication in okta and redirected back to my application. Within this token I see all the user details I need but here comes my question. Do I need to verify that response any futher or shall I just trust what I receice? Considering this token also contains signarure?
My idea for security would be to reach Okta again and verify if this was really issued by Okta. Not sure if this is even possible.
Using NodeJS for verification.
If by SAML response token you mean the samlp:Response issued according to the Web Browser Passsive SSO profile then then response contains an assertion and the assertion is signed by the Identity Provider (additionally, the whole response can also be signed).
There's a critical security requirement to always validate the response signature. This is mentioned in the SAML specs, section 4.1.4.3
The reason for this is as follows: in the Web Browser SSO Profile the token is returned by the Identity Provider in a web page that contains a simple form with SAMLResponse and RelayState fields and a bit of code that just autoPOSTs this form to your app. Technically, this means that for a short time the token is controlled by the user's web browser and this is where the token can be altered (or forged).
Thus, the protocol security heavily relies on the token's integrity which is achieved with the crypto signature - it's just a plain old XMLDSig signature applied to the SAML.
Your goal, as a token receiver is not only to validate the signature but also check the signature's certificate and compare it to the certificate you expect from the trusted provider (or a list of certificates of trusted providers).
Skipping this step makes your application vulnerable:
skipping the verification means users can alter the token (add/create/delete) claims to the assertion, the signature verification would fail but you skip it
skipping certificate matching against known certificate means users can forge their own assertions, sign it using a dummy certificate and present to your application. The signature verification step would succeed but you won't be aware that a dummy certificate was used to sign the assertion
If you don't want to do the proper token validation on a backend (don't blame you, it's a pain), then switch to OIDC. That's a better fit for authentication and authorization for the frontend.
If, however, the SAML response is sent to and handled by a backend, and some other token is being forwarded to your application, then you should evaluate what the requirement for the validation of that token is.
What isn't clear in your question is where in the user flow we're talking about, hence the number of comments on my answer.
I have a question regarding saml workflow when certificates are being requested from the SP.
We are a SP and have implemented sso using saml for a number of customers. We send a standard request (doesn't include any certificate, or request isnt signed) to the clients IDP and handle their response validating their x509 cert which was shared pre-release and have installed on our server.
This is the only work we do with certificates at the moment. We now have a client who is asking for our x509 cert. We currently dont have a certificate, and i'm wondering what changes in our current workflow based on this request.
Do we need to sign our initial response or add the certificate into the body of the response? I'm a little in the dark to whats required from our end and what changes were going have to make.
It clearly is adding some other layer of security but could someone explain the workflow when this extra signing is used ?
Thanks in advance.
They probably want to encrypt the SAML Response containing attribute statements, etc. They would use your public key (i.e. the SP's certificate) to encrypt the payload, and then you (as the holder of the SP's private key) would be the only one that could decrypt that content.
This is a perfectly reasonable request from the IdP.
And realistically, you should be signing your AuthnRequests and LogoutRequests with a certificate. You don't need to provide the encryption cert in the AuthnRequest, the IdP will use the cert in the metadata to encrypt the content.
I am trying to implement SSL pinning and I did, using the didReceiveAuthentication Challenge. I do have a question, however, is that the description of this function
https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455638-webview?language=objc
and so are the URLSession Version of it, both mentioned that only when the challenge is received. My worry is that, would there be website that doesn't ask for client certificate at all? If that is the case, how am I suppose to do SSL pinning then?
Client-side certificate pinning has nothing to do with client certificates. didReceiveAuthenticationChallenge: is called in response to receiving the server's certificate as well. In that case it's called with the protectionSpace.authenticationMethod set to NSURLAuthenticationMethodServerTrust. If the server requests a client certificate, it'll be called again with ...ClientCertificate. If Basic Auth is required, it'll be called again with ...HTTPBasic and so on.
Some time ago I've worked on setting up SSO user authentication in a web application. The specific IdP was an ADFS server, but I don't think that's very important.
When configuring the application's SSO settings, I noticed that the IdP certificate's fingerprint is required, but not the certificate itself. Now, as I understand, the fingerprint is used by the application to validate the IdP's signature on the issued SAML token.
The question is how can the application verify the signature with just the certificate fingerprint? Doesn't it need the certificate's public key, which is part of the certificate itself, but not of it's fingerprint? How does this signature verification process work?
The fingerprint is exchanged out-of-band between the sender and the receiver and is configured on the receiving end. It uniquely identifies a certificate with the public key that the sender uses to sign the SAML messages that it sends.
The certificate itself can then be sent in-band as part of the SAML message itself. The receiver will compare the fingerprint of that certificate against the stored fingerprint to confirm that is dealing with the appropriate sender and associated key before cryptographically verifying the SAML message with that key.
This has the advantage that only a small message needs to be exchanged out-of-band beforehand. This may be useful e.g. when read out over a telephone line but has the downside that the complete certificate needs to be sent with each message (well, in principle at least the first message...) which increases the size of each message.
I learnt something about ocsp recently.
I check ocsp stapling of site by command like:
$openssl s_client -connect www.stackoverflow.com:443 -status -servername www.stackoverflow.com
I found my own site and stackoverflow and some other small sites have ocsp settings. They have OCSP Response Data field in command response.
But when I check some big sites like google.com, github.com, facebook.com, they don't have such a field. And I get OCSP response: no response sent.
So why they don't use it?
To protect your users, as a web server, you must use OCSP must staple. But even in such a situation, you need to consider that OCSP responses that are given are often valid for multiple days, so an attacker can get an OCSP valid status for a server certificate before the certificate was revoked, and insert it as an OCSP stapled status during its MitM attack to a web client (of course, the attacker must be the same that hacked the certificate and for which the certificate has been revoked). So, a browser, that would not support OCSP stapling and that would require OCSP, would be protected. A browser supporting OCSP stapling would not be. This is one of the reasons why OCSP stapling is not the ultimate choice. there are some cases where it is a less secure way to avoid security flaws, and some other cases where it is useless. Even if it is not a bad attempt to get more trust on the Internet, of course.
So, some big companies like Google offer other means to protect their customers and users using their browsers: they want to offer a more secure experience to their users, comparing to other browsers, because their goal is to get more users. For this purpose, Google Chrome implements the proprietary CRLSets mechanism.
The same companies and others also want to promote other ways for people to get (back) trust on the Internet. For instance, some companies follow Google to promote the Certificate Transparency mechanism. So, this would be a bad idea, politically speaking, to implement OCSP stapling on their site and working for another trust mechanism for the Internet.
The best paper I've read about certificate revocation and the means to protect your users is here: https://arstechnica.com/information-technology/2017/07/https-certificate-revocation-is-broken-and-its-time-for-some-new-tools/
My answer is: probably because saving more bytes in response.
Alexandres's answer (specially bolded text) may be correct for google.com, but not for facebook.
OCSP stapled response would be present in every TLS connection and this takes many bytes. Why would happen if no OCSP staple exists in response?! client sends a OCSP verify request to orginal server and caches response for several days. For popular sites like google and facebook, users see pages several times a day, and normally OCSP response is cached at client and no OCSP request is required (e.g. only 2% of clients need actual OCSP request).
So for this popular sites, removing OCSP stapling (and saving a hundred bytes for 98% of requests) is a better choice than making a site faster for 2% of requests.