Is it possible to safely check SSL certificate status by browser access, instead OpenSSL ?

[Rollo62 536]

Hi there,

 

I want to use the TRestClient components mainly under mobile platforms (iOS, Android),
and I want to enhance and ensure the security concept for a new app.
So far that means I need to verify the certifications under all conditions, same like browsers do.
Since I have seen issues with apps which doesn't check certificates properly, but since Rx10.2.2 there should be all the events in place now.

 

The client throws an event OnValidateCertificate, which could be used to verify a certificate,

I think that is the right one, not really the OnNeedCertificate event, as noted in the blog from Marco above.

This event returns certain infos in the TCertificate object, which are helpful to identify and verify the certificates:

TCertificate = record
    CertName: string;
    SerialNum: string;
    Expiry: TDateTime;
    Start: TDateTime;
    Subject: string;
    Issuer: string;
    ProtocolName: string;
    AlgSignature: string;
    AlgEncryption: string;
    KeySize: Integer;
    function IsEmpty: Boolean;
  end;

Unfortunately there is no real simple way to check the certificate status provided, e.g. from a test-site like BadSsl.com.

It seems that this can be achieved only by heavy OpenSSL and touching the OCSP protocol, maybe then the app can be able to check the full status correctly and completely.
While on the other side the native browsers can do this easily, as a side-effect more or less.

 

From my understanding of the System.Net libraries, their basic idea is to use the underlying OS SSL systems,
which works well for the HTTPS connection part.

But I cannot really find any simple way to make use of the underlying OS for checking certifications,
even if everything for checking certificates, like OpenSSL, should be in place in the OS.

 

So I think about using the browsers of the OS, which have such support integrated, and should be perfect candidate to check the status (Safari, Chrome).

But there is also no easy way to get data from the browsers from an app either, or is there any documented way I haven't seen yet ?

 

Moreover,
even if there would be a way to get that data: Would the access to the system browser be considered as "safe", from a high security standpoint ?

There could be still a man-in-the-middle attack taken place, although the risk is IMHO quite low.

 

Is there any simple Delphi/FMX "certification checker" out there which I haven't seen yet, or do I have to re-invent the wheel ?

Maybe some security experts have tips to flatten the way, to reach a high security certification of the apps.

 

 

 

[Guest]

OK this will be long... 

 

First i want to correct and identify the misconceptions and misunderstandings.

52 minutes ago, Rollo62 said:

Unfortunately there is no real simple way to check the certificate status provided,

"check" is not a correct word to handle a certificate, the words should be one of these validate or authenticate, or both as they should be used, because the difference is huge, i am lazy to rewrite in bad English what you can google, but here a sample https://www.geocerts.com/blog/understanding-ssl-certificate-authentication-validation or this https://en.wikipedia.org/wiki/Verification_and_validation

Read the above and google some to get the idea.

 

The whole process will come to two parts, verify ( check may be OK, who knows) the certificate to be valid, means it is not expired, not corrupted, not revoked, have a full chain of trust leading to self-signed one ... etc, the second part is the authentication part, when you or your app deem it as valid and acceptable to be used to establish a secure connection.

 

The first part does has quite few steps to pass, corruption check is easy to do, like expiration date, it get harder to walk check for revocation assuming it does have CRL link, ( Certificate Revocation List) , OCSP likewise...,

the point here is, this process is complicate and not easy to be done 100% right, and as you mentioned high security, then anything less than perfection is called half assed security, or a useless shell, not recommended when your client asked for secure application.

 

1 hour ago, Rollo62 said:

But there is also no easy way to get data from the browsers from an app either, or is there any documented way I haven't seen yet ?

 

Moreover,
even if there would be a way to get that data: Would the access to the system browser be considered as "safe", from a high security standpoint ?

Even if such thing is possible it is highly unrecommended, and in my opinion this is wrong.

 

1 hour ago, Rollo62 said:

Is there any simple Delphi/FMX "certification checker" out there which I haven't seen yet, or do I have to re-invent the wheel ?

Don't waste your time with inventing or reinventing anything, find fully vetted solutions.

 

1 hour ago, Rollo62 said:

Maybe some security experts have tips to flatten the way, to reach a high security certification of the apps.

Here i can help you.

 

In my opinion you have two possible approach's to take, ( this what comes to my mind now and others may be have better solutions)

1) to simplify the point, and you mentioned you want to stick to the component TRestClient, i don't how to sound it better, but i would not trust Embarcadero with anything called security, they couldn't have less consideration for any security for their client or even their own products !

So if it is possible try 3rd party and you will use them for years to come with ease in minds, commercial or paid, take an example ICS it does have its own trust store to validate a certificate in full, but i am not sure about OCSP or CRl.. I think Angus or Francois can help here.

 

2) Second approach is to ditch the whole certificate approach in full or in part, this approach i like and did many time with many variation based on the job, while maintaining bullet proof secure connection, to summarize how this can be done then go through the following and find your best approach

A) use X509 certificate like you want but instead of go through chain of trust, ping its information or its CA ( or even the Root) on the DNS , to explain, when you are resolved the server domain name, your client also grabbed the TXT record of that name, there it would find some information to authenticate the expected certificate(s) form your server, you can use the SHA256 of the whole certificate as raw data, or you can pin the hash and serial number the CA of that certificate( in this case the server should send the CA along with the end one) , and to add if you went with this approach then you don't even need a trusted CA issued certificate, heck you can generate your own and it will be 100% bullet proof, as the application (Server/Client) is yours, 

But there is weak point here to point, how to grab DNS data in secure way ?!, here comes DNSSEC or a simpler way DNS over HTTPS, DNS over HTTPS is gaining popularity fast and you can use cloud flare for that https://developers.cloudflare.com/1.1.1.1/dns-over-https/web-browser/

Have no idea what Delphi library other than SecureBlackBox can DNSSEC, there is others can point if that possible to use Indy or ICS for such usage, the draw back from DNS over HTTPS, that it will return us back to the first point to validate CF certificate to reach the DNS query in secure way, but adding the store of cloud flare, so it is a loop here, unless someone elaborate on how to do this.

 

B) Ditch the certificate in full and switch to PSK keys and their cipher suits(PSK=pre shared key), those doesn't need a certificate, but i have no idea if ICS or Indy or even if any Delphi OpenSSL library allow them or if it is implemented, now while pre shared key sound terrible, it is in fact terrible to be used as what first comes to mind like password for the WiFi router, but you can use it elegantly and again make it bullet proof, my idea and how i use it is like this

Server generate pair of keys, most the time i put the public key on the DNS, but you can embed it ( compile it within the client), client when want to establish a connection it will use PSK key encrypted with the server public key and send it in the client hello message to the server, server will decrypt it and use it to finish the handshake, this will render any MITM attack impossible because, you can do many combination here, instead of encrypt you can initialize DH key exchange (Diffie–Hellman), many possible way to use or tweak while maintain top notch security, without compromising the security and without going in certificate chain of trust maze.

But this approach need ability to use PSK key, again i have no idea which Delphi library or code base allow you to use them.

 

C) Pin your root or CA in your client !, example , simply generate your self-signed root and protect its private key, generate CA from it and also protect it but your server will use its private key to generate a new certificate for connection and will send the chain of these two, on the client side client will validate the certificate and its CA then validate the CA against the embedded root with it !, simple like that.

This will work securely, only the draw back the embedded root can't be changed, so you can either extend the chain to 2 CA's or just update, not so elegant but it is secure, just remember you don't have a way to revoke the CA, but DNS comes to help here as you can build your own revocation list on the DNS, this will be needed if you leaked the CA private key or worse if your root is leaked or lost, a way to work around to simplify things, (as i said always protect your root because losing it will render the application compromised), while make tour CA short term like a day or a week while the end certificate you can make it 4 hours, server will generate a certificate each hour for an established connection the expiry date is irrelevant, this will make you less concerned about revocation list.

 

That few thing you can consider, hope this help, others are welcomed to correct me or shed lights on many things above.

[Rollo62 536]

2 hours ago, Kas Ob. said:

OK this will be long... 

 

First i want to correct and identify the misconceptions and misunderstandings.

"check" is not a correct word to handle a certificate, the words should be one of these validate or authenticate, ...

Yes sorry for that, you're absolutely right.  "check" is a too sloppy term for all these processes.

What I meant by "check" was the whole process itself, including obvious steps, like expiry, and not so obvious tasks, like validation, revokations, ... all that you pointed out.
Of coarse "expiry" check is an easy one, but parsing the revokation list is highly tricky.
 

SecureBlackBox seems to be a good choice, since it supports all platforms I'm interested in

Quote

Support for Windows, Linux, macOS, Android, and iOS.

 

2 hours ago, Kas Ob. said:

5 hours ago, Rollo62 said:

But there is also no easy way to get data from the browsers from an app either, or is there any documented way I haven't seen yet ?

Even if such thing is possible it is highly unrecommended, and in my opinion this is wrong. 

I was afraid somebody would say so

2 hours ago, Kas Ob. said:

In my opinion you have two possible approach's to take, ( this what comes to my mind now and others may be have better solutions)

1) to simplify the point, and you mentioned you want to stick to the component TRestClient, i don't how to sound it better, but i would not trust Embarcadero with anything called security, they couldn't have less consideration for any security for their client or even their own products !

Well, I would not have expected that, but your opinion sounds reasonable.

I usually look after the modern approach, when choosing a new techology.
Indy is still around everywhere, thats fine too, but with HTTPS it always stood behind the new System.Net components,
needed to carry all that OpenSSL stuff in the baggage.

Not that I need to stick to TRestClient, but it looked to me more modern and  I was very happy to see something
like System.Net to ease such basic tasks, especially on mobile platforms.

So also Indy and ICS could be the right choice too for making the connections, but isn't this in the end exchangeable,
after the certificates were validated ?
Then after validation the connection session is, and stays, safe ( of course not counting any TRestClient issues here ).

 

2 hours ago, Kas Ob. said:

2) Second approach is to ditch the whole certificate approach in full or in part, this approach i like and did many time with many variation based on the job, while maintaining bullet proof secure connection, to summarize how this can be done then go through the following and find your best approach

 

A) B) C) .... That few thing you can consider, hope this help, others are welcomed to correct me or shed lights on many things above.

Yes, thanks a lot.  Unfortunately much to consider

I always think, if security is so important and all want this, why the hell must it be that obfuscated ?

I have to look into those options more deeply and check them out.

 

Anyway, are there maybe any other configurations outside of Delphi, that might help ?

Probably server-based security measures, with JWT access-token, separate authentication server, a 3rd party microservice  or the like.

Or specialized libraries from the local mobile platforms itself ?

Yes also the server certificates itself may be compromized, but don't have all the cloud and service providers similar problems,

when offering REST services to an app without a secure browser ?
I think the cloud providers will have to force their users to close all security gaps, also to provide damage from themselves.

 

Would the access-token and key exchange something that could ease or replace the whole security process,
when moving to a more self-signed approach, like you described ?
I think I could omit the CA root references at the moment, not sure if I will need them in a later scenario.

If I consider an access-token as "small certificates", but without the overhead and easy to validate.

I'm afraid then when I cannot rely on the HTTPS transfer, and need my own encryption in the transfer, also thats no easy path.

 

 

 

 

 

 

 

 

 

[Guest]

48 minutes ago, Rollo62 said:

So also Indy and ICS could be the right choice too for making the connections, but isn't this in the end exchangeable, after the certificates were validated ?

 

58 minutes ago, Rollo62 said:

Anyway, are there maybe any other configurations outside of Delphi, that might help ?

Probably server-based security measures, with JWT access-token, separate authentication server, a 3rd party microservice  or the like.

Or specialized libraries from the local mobile platforms itself ?

Yes also the server certificates itself may be compromized, but don't have all the cloud and service providers similar problems, when offering REST services to an app without a secure browser ?
I think the cloud providers will have to force their users to close all security gaps, also to provide damage from themselves.

I am lost here somehow, and not sure if i understand the questions right, are you talking about authenticating the client to server and server to client, or as i was answering on how to establish secure connection to prevent man in the middle, because those are different things, see cloud providers authenticate the user not the client (connection), where user are providing his authorization (token, password, login ..) but those cloud providers can't care any less about the connection as long it is HTTPS ( or TCP with TLS), all of the cloud providers that work with browser throw that ball to the browser to be secure.

 

As for JWT token it can provide you of a mean to authorize and authenticate while guarantee the data is not tempered in client to server and vice versa but it will not provide suitable privacy for the traffic (encrypted or not) without secure connection.

 

Let me give an example RTC SDK, it is HTTP based and it does provide secure, encrypted, private data communication over unsecured HTTP, now you can switch to Windows sockets or add StreamSec, SecureBridge or SecureBlackBox on top of it and you have just switched from HTTP to HTTPS, while the encryption still there needed or not, the encryption can be disabled of course, but still the mechanism to identify and authenticate your user is up to you, and RTC will not provide that out of nothing.

 

Let us look at this in different way, you are developing an application client and server, means you have endless method to authenticate then authorize the user, either the user is person or a connection client, that is up to you and you have full freedom to use any approach secure-right, but when you will allow your server to answer a browser, like any browser, then we are in different realm, and your endless methods now can be count on a hand or two on best cases, and your secure connection is completely depend on the trust chain anchor that is trusted and included/supported by the browser, means you must use trusted CA issued certificate, paid or free as long its root can validated by that browse, you can here use tokens like JWT with HTTP, but you stripped the first well vetted and tested defense wall from your server and exposed it to any attacker to start testing its brute force capability, instead complicate the thing for him, i mean he must go and dissect your client to understand how to establish a connection to server, then after that, try to brute his way on a user login password as an example, with JWT how to make sure delivery of the keys in secure matter, in fact you certificate some might call it a merely container to a public key, but in fact it is more but the key is critical part of it, so even tokens should be exchanged right, at least for the first packet ( simulating a handshake), but if yo can do that right then just replace that with a certificate, right ?

 

on side note about that, Chrome does use Windows store, FireFox does have its own and will not even look at Windows store.

 

Cloud providers can't enforce any specific connection and can't guarantee that privacy is 100% protected, this is up to the user and his software which is usually a browser, eg. for that sometimes you see a browser is more strict (like it should be) about the certificate and domain name correctness , but now most of them are more and more switching to 2FA or at least give the user option to activate such thing, the point is if you are building your own server/client application you have more freedom in choosing a secure approach, while relaxing the whole thing to few steps instead of including JWT and complicating the whole thing assuming the connection might be compromised at every step, as mentioned in the SO answer yes it can but it will have its own drawbacks, like you need to implement replay attack prevention and serialization mechanism let say your client sent three packets A,B and C to server then an MITM dropped B triggering lost data and this should be on both sides, you should be able to detect that, also JWT will perform a signature verification on each packet, this is expensive PKI operation, not cheap on the CPU, while TLS does AES and MAC relatively very fast...

 

1 hour ago, Rollo62 said:

I always think, if security is so important and all want this, why the hell must it be that obfuscated ?

It is not so obfuscated, it is simply intimidating to learn from scratch, it is rightfully should be strict as much as possible, for that the learning curve is steep at first, the problem is with Delphi developers, it was not given any consideration for ages, also the libraries and codes for that matter are scarce or expensive and scarce.

 

Hope that was helpful and clear.

(I am looking at ICS now and not sure if Android is supported or not, while promised in V9)