Using the default cipher values in Kubernetes Nginx ingress controller shows that 2 ciphers are weak:
enter image description here
What are the values i need to set in order to replace the weak ciphers ?
Let's look at this from a bigger picture.
All TLS_RSA ciphersuites have been marked as WEAK because they don't provide forward secrecy: if the private key gets compromised in the future, all recorded traffic can be decrypted using it.
The only major browser that ever implemented those two ciphersuites you listed is Safari, and Safari has supported GCM cipher suites since 2015.
In general, any cipher suite that doesn't say CHACHA20, GCM, or CCM is now marked as either weak or insecure.
You could replace them like below:
ECDHE-RSA-AES256-SHA384 to TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
ECDHE-RSA-AES128-SHA256 to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
but according to this source:
SSL Labs identifies cipher suites using CBC with orange color and with
text WEAK. This change won’t have any effect on the grades, as it only
means that SSL Labs discourages the use of CBC-based cipher suites
further.
All ciphersuites utilizing Cipher Block Chaining CBC aren't automatically WEAK, but there have been so many implementations vulnerable to padding oracle attacks that they have decided to mark them all as WEAK.
Another option would be to completely remove those two values and use DHE ciphersuites as long as they have key length of at least 2048 bits and use GCM mode: DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES128-GCM-SHA256.
You can also consider removing them completely but you actually don't have to because your implementation was not marked as vulnerable. Only implementations that are vulnerable to the new Zombie Poodle and Goldendoddle vulnerabilities will be graded F.
I hope it helps.
Related
Is it possible to have a FIDO2 usb key which I can use as a second factor without requiring me to perform the user presence check? All the keys I've checked so far (YubiKey, Solo Keys, etc.) require me to tab them.
The intention is to use such a key in order to verify that the authentication process was really initiated from my computer and nothing more. That means, I do not care if my computer gets cracked and then some bad guy performs an authentication via my computer. However, the key would at least prohibit others to authenticate as me from other devices. Having a "tab-less" FIDO2 key would be really convenient (for example, I would like to use it for my SSH keys, however, tabbing the FIDO key every time I login is cumbersome).
All FIDO2 devices have silent authenticator mode(no UV and no UP). This is done by setting specific flags during the request to the authenticator. (UV=0 and UP=0. And need to check if GetInfo has UV and/or UP set to true(available)
However, browser don't have this option right now(as of NOV 2020). This is because there are security and privacy implications. There are some discussion about how this can be properly implemented, so in future websites might be able to use that.
The ssh-keygen command from OpenSSH (since 8.2p1) has the -O no-touch-required option that will not require tapping the key. Note that the SSH server has to be setup to allow this, e.g. by adding the no-touch-required to the respective authorized_keys entry.
This is against the FIDO standard and user presence or user verification is a mandatory feature of a certified CTAP product.
you can use, open-source key and have your modified key to respond to user presence automatically.
Is it possible to use a wildcard SSL certificate to sign other certificates?
i.e. I have bought a root signed wildcard certificate for *.example.com
I want to allow a third party to provide a service for me, on thirdparty.example.com.
Is it possible for me to create a certificate for thirdparty.example.com and sign it using my *.example.com cert? Or do I have to buy a separate cert for the third party.
If this is not possible, is it possible to buy a domain-signing-cert? Just to be clear, I only want to sign certs for .example.com, not a root level (.com) signing cert.
No, you can't (although it is technically possible, but it won't work). Because certificate signing certificate must have two extensions with the following values:
Basic Constraints must be set to CA=True and be marked as critical
KeyUsages extension must have a keyCertSign and cRLSign bits enabled.
is it possible to buy a domain-signing-cert?
yes, it is possible, but it would be very expensive for you (if you don't plan to issue a large number of certificates). Because you will have to pay a huge price for this service, buy required hardware (HSM is mandatory), write documentation (CPS at a minumum) and process external audits to verify whether you comply with provider's CPS (certificate practice statement). Several time ago I wrote an article about root certificate signing: Certification Authority Root Signing.
HTH
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
So, I'm brand new to creating a https-compatible site.
I'm currently working with a client with whom I developed a custom Facebook tab for; the files are currently hosted on my server which I have not purchased a security certificate for.
My client has a security certificate for one of their websites, which I do not have access to. My client sent me a text file with a combination of letters and numbers, and I have absolutely no idea what I'm supposed to do with it.
Anybody have any clue how I'm supposed to use it?
In short, you (probably) can't use it for that. But we need to check to be sure.
Background
As you know, SSL is used to secure the communication between two systems, one a server and the other a client (well, for the purposes of this communication link anyway). For the code that sits on initiating, client end of the communication channel to know that it's talking to the right server, it needs not just to have secure communication but also the identity of the server. (Without that, DNS spoofing or any number of IP-level tricks would be utterly massive problems.) This is where certificates come in.
Servers have a cryptographic identity (a public/private key-pair) that they use as part of the boot-strapping of the SSL connection which proves who they are. The public part of that is told to anyone who asks, and the server proves that it has private part through the fact that it can do the key-pair based cryptography (basically, that's mathematical magic, a.k.a. number theory). Then, all the client has to do to know whether to trust the connection is to work out whether they trust the identity stamped into the public key. This can either be by having been previously told directly “trust this certificate” or by the fact that it was digitally signed by someone it trusts (which is how the Certificate Authority system works).
A certificate is basically the public key of a key-pair, at least one digital signature, plus additional information. Examples of the additional information that could be there are the name of the host for which this is a certificate, the period of time for which the certificate is valid, who the administrative contact is, or where to go to find out whether the certificate has been withdrawn early. There are many other options.
What to do with a bare certificate?
With a bare certificate (in PEM format, as you say) all you can do is add it to your collection of trusted certificates or look at the information encoded within the certificate. So we'll start by looking at the information. For that, we use the openssl program (which has a horrible command line interface):
openssl x509 -in thecert.pem -text -noout
That will splurge a whole bunch of information out. The most important part is the “Subject” field; what or who is this certificate talking about? Since this is about HTTPS (which imposes a few extra constraints of its own) we should check whether that contains a hostname of some kind, and what host it is talking about.
Now you have the information to be able to figure out what's going on.
If the whole certificate matches up (especially the digital signature) with what you've already got deployed on your own HTTPS-enabled server, then your customer has just sent you back something you already have. Ho hum.
If the hostname is for a machine that you control and your customer doesn't (e.g., your development server) then your customer has just tried to get a certificate on your behalf. That's a bit of a no-no, but I advise taking it well — especially if you've not yet set up HTTPS. For the purposes of testing, you can get your own single-host certificate (that signs a public key where you've generated the private key yourself) for next to nothing. It's also a reasonable expense to bill your customer.
If the hostname is for the machine where the customer has told you they want to deploy your code in production, then they've just given you something you don't really need. I suppose it might be relevant for client code that wants to connect to the deployment server, but that's not as useful as all that; certificates expire, stuff moves round, and all sorts of things happen in production that can mean that it is useful to issue a new server certificate. Having to push updates to all the deployed clients just because someone accidentally deleted the server certificate without keeping a backup (a more common thing than you might wish) would Truly Suck. Thus, the deployment host certificate is not something you should need.
If its none of these, and it's a long lived certificate (check the Validity field from the information you printed out before) then it might actually be the certificate of a back end service that you're supposed to talk to. Or the certificate of a private CA that signs all the certificates of the back-end services that you talk to. (Are you doing this? I don't know, and I don't know your app, but it's quite possible.) In this case you would add the certificate to the list of trusted certificates in your code (the exact way depends on how your code handles SSL) and this is the only use I can think of for a certificate at the stage you're at.
Trouble is, I don't think (on the basis of what you write) that it's all that likely. Talk to your customer; security is something where you want to get it right, and use and trust of certificates is key to that.
If it's truly none of the above, talk to the customer and say you're a bit confused. I know I am in this case!
We develop a Win32 program (=host) which allows 3rd party to write plug-ins. As some plug-ins contains valuable piece of code (for example, high quality video scalar), the 3rd parties want to limit their plug-in to work only with our host program.
Our idea is to use Microsoft Authenticode technology to sign the host. Then, the 3rd parties are asked to implement the following algorithms to check the host. (The 3rd parties are expected to do sufficient code obfuscation for the algorithm).
Use WinVerifyTrust() API to verify the certificate of the host is valid (= Not revoked, not tampered, etc).
Verify the certificate that the subject is our company.
The question is about step (2). The 3rd parties cannot simply check thumb print or serial number because the digital certificate of the host will be renewed after the certificate expiration date.
My idea is to check parts of subject's distinguished name, specifically "country (C)" and "common name (CN)", assuming that there is no company name confliction in the United States. We shouldn't check other attributes such as state and city because our company might move - in fact, we have moved from one city to another just a year ago.
Question: Is it good way to accomplish the goal?
While the scheme is workable, it's possible to relatively easily circumvent protection by just patching plugins so that they ignore the signature or skip signature verification altogether.
What is even more important, - if you plan to have multiple plugins/vendors, you would have hard time ensuring that all vendors obfuscate validation code right.
Then, I'd say that it can be against plugin vendor's interest to limit their plugin to your application only - if they want bigger market, they might want to have the same plugin run on wider scope of hosts.
Can anyone please tell me if Certifying Authorities (CAs) are allowed to make modifications to the Certificate Signing Request (CSR) before actually signing the certificate with their own private key?
Specifically, I'd like to know if it's valid for the CA to insert additional fields (such as EKUs) into the cert before adding their signature.
Yes
The Certificate Authority is responsible for enforcing the organisations PKI security policy via its policy files and templates. This may include EKU (extended key usage) attributes.
In reality you are requesting a certificate of a certain type from the CA on behalf of your subject. It is up to the CA to enforce the type of certificates (and the associated uses) that it will issue.
The CA is not actually modifying the request so much as issuing a cert of a permitted type.
I can't speak about CAs in general, but I once ran a Windows Server 2003 network with its own CA, and it's definitely possible to make certreq (through the -attrib option) add additional fields to the CSR before it gets to the CA. Thus, it looks to me like it's possible for the CA itself to do much the same thing.
Your mileage may vary.