Is there is any way to get around the SSL certificates in the wallets expiring, having looked at the expiry date that is in the wallet.zip README file as well as the orapki utility.
If one cannot get around SSL certificates expiring what is the recommended way of managing SSL certificates and their expiry?
Autonomous Database takes security seriously, so there's no way to get around an encrypted, secure connection and you will need to download new wallets before their expiry date. You can have multiple wallets with different expirations concurrently, so there is no service interruption.
Depending on your application, you may also consider enabling mTLS to go walletless, which we released recently! Read Todd Sharp's post about this as well as the ADB documentation for more detail.
Ref: I am a product manager on the Oracle Autonomous Database :)
Related
I have a successful connection with an ESP32 and aws. Now, I have read, that the certs have an expiration date. So is it possible to extend the date or is it necessary to change the certs. If it is necessary is there a way to change it automatic?
If you use the certificates that AWS IoT core generates for you, then they will expire at midnight UTC on December 31, 2049. The same site states:
Devices and clients must also support rotation and replacement of certificates to help ensure smooth operation as certificates expire.
So if you expect your ESP32 to live and work for almost 28 years, then you have to make sure you can rotate/replace the certificates. You could write some software that enables you to change the certificates through AWS IoT jobs. Generate a new certificate before the current certificate expires. Put the new certificate on S3 and send a pre-signed URL to your device through an AWS IoT job that will trigger a script (you have to write this script) to download the new certificate and replace the current one.
Keep in mind that it's likely you won't only have to replace the device certificate sooner or later but also the CA, in case it expires or AWS decides to change the root CA. Which happened before.
Alternatively, you can create your own CA with its own expiration date and use this for your device. In this case you could set your expiration date to 100 years in the future, which would be fine for your private setup but not for production use with multiple devices distributed across the country or even globe.
If what you're doing is unimportant (like a hobby), you could modify the code to just skip the step of authenticating the connection destination via a CA. That way it would work forever, or until someone bothered to attack you as a "man in the middle".
For AWS IoT things, I think you can make/upload your own certificates to AWS IoT Core which could last ~ 80 years, I estimate.
I have not tried these methods yet.
I'm using SSL certificates in a client-server application; both the client and the server are using 2 certificates that will expire soon. Normally, you'd just replace the certificates with new ones, but this cannot happen at once because of the huge numbers of clients.
So, if only the servers and a part of the clients are updated, the rest of the clients won't be able to authenticate anymore.
A quick fix is to replace the binaries with a version which simply disregards expiry date of the certificates; the update of the clients can be done sequentially, as long as it will finish before the certificates expire.
Long term solutions I thought about:
use Puppet to push new certificates on clients
unfortunately, not viable because not all clients are/will be managed via Puppet
use a second set of certificates
if first set has expired, use the second one
in this manner, server will have new certificates, a part of clients will have new certificates and the rest of the clients will have old certificates, but everything works
client requests a new certificate from the server, if the current one has expired.
Are there any other solutions?
I assume you use the SSL certificates for an online SSL connection, like HTTPS, or SFTP.
The big question is: Do you still trust and want to use your server-side key! If so you can just re-issue the server certificate with a new expiration date still using the old key and thus extending the lifetime. The question is, if you still trust the old key or if it should be replaced. Old clients may still connect to you at that point.. You are still using the same public / private key pair, just made a new 'lifetime version' of the certificate for it. (That is what most public servers do..)
Using two sets of active SSL certificates for different keys on the server side is not really viable and only possible if you have good control over the handshake process on the client side and your server application supports it. The issue is that during an SSL negotiation, the server has to send its certificate first and the only indication it might get from the client is a ServerName extension during the ClientHello. (Assuming the client actually sends one). Otherwise the server is 'at a loss' on what the other side will or will not support. (There are some other extensions that might help for in indicating supported CA certificates, but your clients should support those).
The first is the most practical for the clients that do support it. Just renew their certificates (and perhaps keys) and push them. And you are done with those.
For the others, updating the client software and making sure they generate a new key and request a new certificate from the server when they need it (or in advance) might be the best solution.
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
My OSCommerce site includes a separately programmed feature for which I use SQL tables. I've decided to host its tables on a remote site offering free SQL accounts. I'd like to know if there could be any disadvantages to this approach.
Thanks
Syd
Disadvantages might include the longer time it will take to run the script since it has to make a connection over the network and the need to make sure that the database connection is made securely -- that the password for the database login isn't passed in clear text & that the permissions on the receiving end of the connection are set to allow connections from only that IP. Of course you'll also want to make sure that the free hosting company provides adequate security for the database itself -- "free" doesn't alway pay for the best set up or the most knowledgeable technicians...
You should connect to your MySQL database using MySQL's built-in SSL ability. This insures that all data transfered is highly protected. You should create self-signed x509 certificates and hard code them. This is free, and you don't need a CA like Verisign for this. If there is a certificate exception then there is a MITM and thus this stops you from spilling the password.
Another option is a VPN, and this is better suited if you have multiple daemons that require secure point to point connections.
I am assuming you are hosting the OSCommerce database on the same server as the webserver and your solution only allocates one database per customer. You can use the add-on tables in the same database as the regular OSCommerce tables as long as you prefix them with some prefix so that they won't have a namespace conflicts. If the code to the third party solution is any good, it won't be too hard to configure a table prefix so that the code will know what the new names for the tables are. This solves any potential latency problem and keeps the control in your hands. I use this trick to host multiple wordpress blogs in the same database.
One of my friend is working on issue related to updating expired digital certificates.
He is working on Java application(Swings I guess), which has 4000 clients. All those need a digital certificate to connect to the application and this certificate expires every year.
At the end of year he needs to update the certificate credentials for all clients. Currently this is manual process, done by connecting to each of 4000 systems either locally or by remote connection.
He is got task to convert this process to be an automated process.
Normally the client-side certificate (used by authenticating the client on the server) needs to be passed to the client physically (on the carrier), otherwise, if the certificate is sent via electronic channels, there's a high risk of interception. But if secure connection is used, then the problem becomes less critical.
So the answer depends on how the client-side application is built. The easiest approach would be to add capabilities to refresh the certificate (before it expires) right from the application. The application would request fresh certificate from the server.
If no such capabilities are built-in and there's no way to add them, then the answer would depend on where the client-side application stores the certificate, used for authentication. If it's some file, then automating remote desktop connection using some automation tool would be the only choice.