OPC UA allows for using different certificates and private keys for establishing the secure channel and for creating the session, i.e. authenticating the client.
I'm creating a client to connect to an OPC UA server and I'm trying to keep thins as simple as possible, therefore I'm considering allowing to set just a certificate and private key, and if certificate authentication is desired then re-use that very cert. and private key.
Is this a safe assumption or are there real world reasons not to couple the secure channel and the session to the same certificate?
That's how the applications usually do it, when using UA TCP transport protocol, so yes.
With HTTPS transport, you will need a separate certificate for transport and authentication. But HTTPS is optional.
In an Android client that I wrote, in the settings, the user can choose the common name of both certificates and they are automatically created
That helps the server administrator to identify who the connection attempt corresponds to, although if the user puts the same name for both then the same cert is used for the secure channel and session.
Related
Is there any way that I can create a proof of a file downloaded using https? With proof I mean a cryptographic record of some sort that links the contents of a file to a site at a certain time. If I understand TLS correctly, the server certificate is only used as a basis to establish a session key that is known to both parties, so each request is not signed but just encrypted for transfer. Any ideas if this can be done and if so how?
In HTTPS the certificate is only used for authentication and with the obsolete RSA key exchange also for key exchange. Application data are only protected against modification by some man in the middle but they are not signed by the sender. While a HTTP server could be explicitly implemented to sign and timestamp the content, one can not enforce such operation against an arbitrary existing server.
For more see
Where in a TLS connection can I get the signature of the content sent by the server?
Why does HTTPS not support non-repudiation?
How to prove some server sent some file over HTTPS
Proving authenticity of data accessed over TLS by an untrusted third party
I am developing an app with a server part programmed in Go and a client programmed in C#, the connection between the two is made using TCP socket communication, and to ensure the connection I am using TLS.
My question is whether there would be any security problem in my case when using self-signed certificates for TLS communication.
I understand that for a web server that uses https it is necessary to use certificates signed by a certificate authority (CA) but in my case, when connecting my own client application I don't see why I should use one of these.
If anyone knows anything about it, it would be a great help.
Certificates are used for authenticating the end points, and usually the cert is signed by a certificate authority which your client (such as a web browser) already trusts. Using a self-signed cert in that scenario can lead to problems, as the browser won't trust it, and so will pop a warning box. However, the real issue is that for the typical user, a warning from your server is as good as indistinguishable from an attacker using another self-signed certificate. They'll click-away and KABOOM!
If this is a closed environment, and you control both the server and client, then the self-signed certificate is irrelevant. In fact, you don't even need one at all, and may be better off with one of the alternatives, like TLS-PSK, or TLS-SRP.
I do not know is it correct way or not but I am trying to get certificate from macos keychain and use it on flutter httpclient to establish a Certificate based connection. I just wonder is it possible or not.
For now i can get the certificate with native code with and i am returning the data:
var certificate: SecCertificate?
SecIdentityCopyCertificate(identityNotNil, &certificate)
let data = SecCertificateCopyData(certificate!)
then i try to use it like inside flutter:
SecurityContext context = SecurityContext.defaultContext
..useCertificateChain(certificateByteArray, password: 'password');
var _client = HttpClient(context: context);
but i am getting error about bad certificate. Maybe there is a way to reach keychain directly from flutter.
Thank you.
To be more specific, i am trying to use a certificate like :
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_certificate-based_connection_to_apns
I assume that your question relates to flutter web - not a standalone Mac OS application? Then I can think of the following scenarios:
Use client certificates to establish an SSL based secure transport layer with certificate based authentication.
Use client certificates to exchange encrypted messages with encryption done by the application (both client and server) or use client certificates on the application layer for Authentication only.
Scenario 1: SSL with client certificates
In flutter web, HTTP Connections are only supported via XMLHttpRequest - the underlying JavaScript Object - under the hood flutter web code is transformed into JavaScript code. XMLHTTPRequest does NOT support any Client Certificates.
But you can configure the Browser to use client certificates when connecting to a WebServer via SSL - this would be fully transparent to the flutter web app. All modern browsers support client certificates and do access the MacOS keychain.
Of course, the server need to support SSL with client certificates. E.g. if you want to use client certificates in order to authenticate to a Spring Application based on SSL client certificates, this is described here:
Spring Security - Pre-Authentication Scenarios
Scenario 2: Application layer encryption/authentication
This is a very unusual scenario, as web applications usually rely on SSL for many good reasons: No coding is required and its pretty secure. But of course, it is technically feasible to implement encryption of all messages exchanged with the server on your own.
Letting aside the pure coding work (encryption libraries also exist for flutter), the key problem is to get the certificate and the private key into the application. Loading the certificate from the server without prior authentication (like the web app itself or all assets) would be a major security flaw, because then an attacker could also easily download the certificate/private key.
The only secure way I can think of, is to obtain the certificate and private key form the client computer. Unfortunately, a flutter web app - like every JavaScript app - is running in a Sandbox within a Browser, which puts major constraints on the application - for good Browser security reasons. Due to this sandbox, the flutter web app CANNOT access the Mac OS keychain directly.
But you can let the user pick a file with the certificate and private key. This is described here:
How to Pick files and Images for upload with flutter web
Is it possible in SSL/TLS handshake where client only send its certificate. Server need not to send any certificate ?As of now in one way handshake only server send its certificate to client.
As i am aware of that in this scenario server needs to maintain all clients root certificate(if diffrent).This is not practical.If possible what are the security concerns.
Here is context under Use of SSL with socket programming in C# or C++
Thanks for help!
Yes, it is possible to use SSL/TLS without a server certificate. See https://security.stackexchange.com/questions/38589/can-https-server-configured-without-a-server-certificate
You need software that supports at least one of the anonymous cipher suites SSL/TLS supports, such as TLS_DH_anon_WITH_AES_128_CBC_SHA256. Per the OpenSSL Diffie Hellman wiki entry:
Anonymous Diffie-Hellman uses Diffie-Hellman, but without authentication. Because the keys used in the exchange are not
authenticated, the protocol is susceptible to Man-in-the-Middle
attacks. Note: if you use this scheme, a call to
SSL_get_peer_certificate will return NULL because you have selected an
anonymous protocol. This is the only time SSL_get_peer_certificate
is allowed to return NULL under normal circumstances.
You should not use Anonymous Diffie-Hellman. You can prohibit its use
in your code by using "!ADH" in your call to SSL_set_cipher_list.
Note that support for such cipher suites and configurations in most available SSL/TLS software is either non-existent or very limited, as such configurations are vulnerable to man-in-the-middle attacks - one of the very things SSL/TLS is used to prevent. You'd have to compile your own OpenSSL code, for example.
Unless you control the software at both ends of your communication channel(s), effectively there's no way to implement such a system.
And there's no real reason to implement such a system as it's not secure at all.
But you can do it with a lot of effort.
Server Certificate which contains the public key part of its key pair is must. The client may decide to overlook the authenticity of the certificate( Its bad!) but the TLS handshake requires the public key for the generation of pre-master-secret. So no way you can prevent server from sending the certificate.
Server if it wishes can request client for its certificate. This is for authenticating the client.
I have a mobile app that will be communicating with my webserver over https. My question is, do I even need to worry about installing a certificate since all traffic to this api will be headless?
In my understanding, SSL provides the encryption for a request, and a certificate establishes trust for the end user. Because these calls to my webserver will essentially be headless, I'm thinking I don't need to worry about the trust establishment.
Am I correct in this thinking?
You will either need a self-signed certificate or a CA-signed certificate in order to use HTTPS on your server.
If your certificate is not assigned to you by a certificate authority, then any connection you make will trigger an error in your URLRequest that you will have to handle. The problem with an untrusted certificate is that a malicious man-in-the-middle could fake data to and from your server with his own self-signed certificate, and possibly pick up authentication credentials or data that he should not have access to.
If you are dealing with any authentication credentials or other private data, I'd recommend just requesting a signed certificate. If you shop around, you can find cheap signed certificates for $10-20 a year, which is a trivial cost to protect your users.
However, if this is just a personal project (the only data you have to worry about is yours), or any data that you will be sending is freely available, a self-signed certificate may be enough.