I have written my own code to connect to Firebase via the REST interface. Recently I have been unable to connect to firebaseio.com because the secure connection cannot be established with the CA certificate I am using.
I am still able to create a secure connection to googleapis.com to handle the login authentication and get the tokens I need for communication.
How do you determine what certificate is needed to validate the connection? I have tried a few of the root CA certs available at https://pki.goog/repository/ but they do not seem to work for firebaseio.com.
WireShark to the rescue! I was able to see the name of the certificates being passed to my device. Firebaseio.com is using one of the certs in this list that I had not tried yet.
After adding that one I was able to connect. How often does Firebase change these certificates? What is the proper method to keep my device up to date with the latest certificates?
Related
I'm going to be using gRPC for a device to device connection over a network (my device will be running Linux and collecting patient data from various monitors, gRPC will be used by a Windows client system to grab and display that data).
I obviously want to encrypt the data on the wire, but dealing with certificates is going to be a problem for various reasons. I can easily have the server not ask for the client cert, but so far I've been unable to find a way around the client validating the server's cert.
I've got several reasons I don't want to bother with a server cert:
The data collection device (the gRPC server) is going to be assigned an IP and name via DHCP in most cases. Which means that when that name changes (at install time, or when they move the device to a different part of the hospital), I have to automatically fixup the certs. Other than shipping a self-signed CA cert and key with the device, I don't know how to do that.
There are situations where we're going to want to point client to server via IP, not name. Given that gRPC can't do a cert for an IP (https://github.com/grpc/grpc/issues/2691), this becomes a configuration that we can't support without doing something to give a name to a thing we only have an IP for (hosts file on the Windows client?). Given the realities of operating in a hospital IT environment, NOT supporting use of IPs instead of names is NOT an option.
Is there some simple way to accommodate this situation? I'm far from an expert on any of this, so it's entirely possible I've missed something very basic.
Is there some simple way to set the name that the client uses to check the server to be different than the name it uses to connect to the server? That way I could just set a fixed name, use that all the time and be fine.
Is there some way to get a gRPC client to not check the server certificate? (I already have the server setup to ignore the client cert).
Is there some other way to get gRPC to encrypt the connection?
I could conceivably set things up to have the client open an ssh tunnel to the server and then run an insecure gRPC connection across that tunnel, but obviously adding another layer to opening the connection is a pain in the neck, and I'm not at all sure how comfortable the client team is going to be with that.
Thanks for raising this question! Please see my inline replies below:
I obviously want to encrypt the data on the wire, but dealing with
certificates is going to be a problem for various reasons. I can
easily have the server not ask for the client cert, but so far I've
been unable to find a way around the client validating the server's
cert.
There are actually two types of checks happening on the client side: certificate check and the hostname verification check. The former checks the server certificate, to make sure it is trusted by the client; the latter checks the target name with server's identity on the peer certificate. It seems you are suffering with the latter - just want to make sure because you will need to get both of these checks right on the client side, in order to establish a good connection.
The data collection device (the gRPC server) is going to be assigned
an IP and name via DHCP in most cases. Which means that when that name
changes (at install time, or when they move the device to a different
part of the hospital), I have to automatically fixup the certs. Other
than shipping a self-signed CA cert and key with the device, I don't
know how to do that.
There are situations where we're going to want to point client to
server via IP, not name. Given that gRPC can't do a cert for an IP
(https://github.com/grpc/grpc/issues/2691), this becomes a
configuration that we can't support without doing something to give a
name to a thing we only have an IP for (hosts file on the Windows
client?). Given the realities of operating in a hospital IT
environment, NOT supporting use of IPs instead of names is NOT an
option.
gRPC supports IP address(it is also mentioned in the last comment of the issue you brought up). You will have to put your IP address in the SAN field of server's certificate, instead of the CN field. It's true that it will be a problem if your IP will change dynamically - that's why we need DNS domain name, and set up the PKI infrastructure. If that's a bit heavy amount of work for your team, see below :)
Is there some simple way to accommodate this situation? I'm far from
an expert on any of this, so it's entirely possible I've missed
something very basic.
Is there some simple way to set the name that the client uses to check
the server to be different than the name it uses to connect to the
server? That way I could just set a fixed name, use that all the time
and be fine.
You can directly use IP address to connect, and override the target name in the channel args. Note that the overridden name should match the certificate sent from the server. Depending on which credential type you use, it could be slightly different. I suggest you read this question.
Is there some way to get a gRPC client to not check the server
certificate? (I already have the server setup to ignore the client
cert).
Is there some other way to get gRPC to encrypt the connection?
Note that: Even if you don't use any certificate on the wire, if you are sure the correct credential type(either SSL or TLS) is used, then the data on the wire is encrypted. Certificate helps you to make sure the endpoint to which you are connecting is verified. Failing to use certificates will leave your application to Man-In-The-Middle attacks. Hope this can help you better understand the goals and make the right judgement for your team.
For the past few days, i've been trying to configure freeradius to authenticate wifi clients in OpenLDAP (without TLS - 389 bind).
I tried several guides and did not get the result i was looking for.
At localhost, RADTEST works and i receive an Accept-Accpet.
User is found within LDAP and accepts authentication.
When i try to authenticate via wifi (Windows 10), i can't connect.
The configuration i am currently using is this:
https://gitlab.com/ae-dir/client-examples/-/blob/master/freeradius/radiusd.conf
Someone with experience integrating freeradius with openldap?
I need wifi clients to connect with their ldap credentials.
You have not explained more details about the authentication method you are trying to use. This is important. However, a simple recipe for making freeradius+ldap authentication work with Windows10, Ubuntu and Android in EAP/TTLS mode is as follows:
Make sure the radius server has access to the LDAP server. Also make sure that the clients (access points) have access to the radius server. Check firewall issues and freeradius configuration (for Debian10 the file is /etc/freeradius/3.0/clients.conf)
For the authentication test (taking into account that the previous step has already been certified by you), there are two interesting tools: radtest (part of the freeradius-utils package) which does not support EAP/TTLS authentication, and a tool called eapol_test, which is part of the wpa_supplicant package and supports EAP-TTLS.
Follow the EAP/TTLS configuration steps and how to use the eapol_test tool on this link.
Make sure you generate the new certificates (don't use snakeoil certificates at all) and don't forget to change the certificate settings in /etc/freeradius/3.0/mods-enabled/eap). The link from the previous step does not talk about this step.
Run freeradius in full debug mode to find any errors (ie freeradius -X).
Don't forget to check the password and protocol compatibility list.
i m using Weblogic 12c.
I would like to set up client certificate authentication (2-way SSL). But i do not want to enforce client certificates for the whole server. Basically, in our webapp most of the servlets should work with regular 1-way SSL (only server certificate is verified) without requiring client to provide the certificate. But for one of the servlets client certificate authentication is needed.
I have set up similar thing for Glassfish using separate module for the servlet where 2-way SSL is required with web.xml deployment descriptor with login-config element indicating CLIENT-CERT authentication type. I have also set up appropriate security constraints, roles and groups.
However this does not seem to work with Weblogic. In the admin console under SSL i see "Two Way Client Cert Behavior" with 3 possible values: "client cert not requested", "requested but not enforced" and "requested and enforced".
If i set it to "not requested", client does not present any certificates at all (even though i have the same web.xml with CLIENT-CERT which works with Glassfish). Setting to "requested and enforced" is not an option. I also tried setting to "requested but not enforced" but that's also bad since the browser will ask for client certificate even for those pages where it is not needed (most of them) and we don't want that behavior.
Basically, it seems to me that Weblogic wants to enforce 2-way SSL for the whole server, but that's not what we need, we need it only for one webapp module. Is it possible to do so?
Edit:
To clarify, i set up DefaultIdentityAsserter and created custom UserNameMapper to map client certificate to user name. The problem however that if SSL setting (described above) is set to "not requested" then client certificate is not presented at all so the server cannot authenticate and i get 401 response. And i can't use the other 2 SSL settings because then the server will ask for client certificate for all webpages and that's not what we want.
You could create 2 Network Channels. See NetworkAccessPointMBean in WLST, or Environment/Servers/yourServer/Protocols/Channels in Admin Console.
Channel 1: SSL enabled w/ one-way SSL, on a specific port
Channel 2: SSL enabled w/ two-way SSL and client cert enforced, on a specific port
Then, access your web module on the appropriate port based on your client cert requirements.
This would only require one server.
For your specific need, I would create 2 managed servers, setting up only one with 2 way SSL.
You can then deploy your applications on the appropriate managed server, depending if you want the 2 way SSL or not for it.
Then you need to add a reverse proxy in front of your WebLogic server in order to forward your user to the correct port, as you probably don't want to expose several ports.
I received the following question. Any help would be greatly appreciated!
What I need to be able to do is configure SSL to validate the target endpoint’s SSL certificate against the base trusted roots (typically provided by the OS and/or Java). There is no documentation that tells me how to turn on SSL certificate validation or if I add a TrustStore if it will guarantee that the SSL cert is validated against that. The only tutorial I see that is related is for SSL Client Auth, which we are not using.
Validation of backend SSL server certificates is explained on this page. Note that the page documents how to achieve mutual authentication, where the gateway would both validate the target server's SSL certificate (which you want), and send a certificate to the target as identification (which you do not want).
To validate the target's certificate, you create a truststore and upload all certificates in the trust chain for your target server. The documentation mentions only uploading the target server's certificate (which works if your target server is using a self-signed cert), but you'll want to upload the entire trust chain of certificates if you are using a non-self-signed cert. Creating and uploading to the truststore is shown in step 6 on the page above.
Then, you'll want the target endpoint configuration to look like this:
<TargetEndpoint name="default>
<HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>false</ClientAuthEnabled>
<TrustStore>myTruststore</TrustStore>
<IgnoreValidationErrors>false</IgnoreValidationErrors>
</SSLInfo>
<URL>https://myservice.com</URL>
</HTTPTargetConnection>
</TargetEndpoint>
ClientAuthEnabled=false indicates that the gateway will not send a certificate to the target.
IgnoreValidationErrors=false will cause the connection to abort if the certificate returned by the target cannot be validated using the certificates in the truststore. IgnoreValidationErrors=false is the default, so you could leave it out and it would work as desired. However, if you are having problems communicating with your target server, it may be useful during testing to set the ignore flag to true to allow communication even if the certificate fails verification (just to isolate your problem). Just be sure to set it to false in production.
The xsd schema for the SSLInfo element can be found here.
I've a quick question:
I have 2 websites, 1 has some links to file downloads. Those files are hosted on another server.
I need to encrypt the request data between the 2 servers..can I do it just using a SSL certificate?
Any other/better idea?
Those files are private docs, so I don't want the server 2 or any other people being able to track the file requests between the servers.
Thanks
Yes, use SSL (or actually TLS) if you want to achieve transport level security. If these are two servers that you control you can configure your own self signed certificates. If you want to make sure that only the two servers can communicate with each other, then require client-authentication, where both the server and client use a certificate/private key pair.
Most of the time the trick is to implement a sensible key management procedure. Setting up a web server to handle TLS using certificates should not be too hard.
SSL certificate will work fine for ensuring the transfer is encrypted. Even just a self signed certificate will be fine for this purpose (provided you can tell the client you're going to use to accept the self signed cert)
Alternatively if it's two linux machines then scp (secure copy) is a great tool where it'll connect via ssh and grab the files. (There probably is a windows scp tool but I don't know it)
Rsync also supports going via ssh
As for tracking the request... there's nothing you can do to prevent any device between your computer and the destination computer logging the fact a connection was made but the encryption should prevent anyone from getting to the actual data you're sending.