I think the answer to this is no, but don’t understand why this feature is not available, I’d like to configure a list of ciphers on a per backend basis i.e to be able to use ssl-default-server-ciphers in each backend section rather than having to use ciphers on each server line. I don’t want to use ssl-default-server-ciphers in the global section as each backend can have a different set of ciphers.
I can't seem to add formatted text in comment reply, so I'll address the response below by clarifying the question here. Backends DO have an option to specify ciphers, here is an edited example from one of my configs:
backend https_be
server 10.255.2.5 10.255.2.5:443 ssl ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256
server 10.255.2.6 10.255.2.6:443 ssl ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256
What I'd like to be able to do, and would be much cleaner is:
backend https_be
option ssl-default-server-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256
server 10.255.2.5 10.255.2.5:443 ssl
server 10.255.2.6 10.255.2.6:443 ssl
But haproxy does not seem to support this, I don't know why, it would be a useful think to do AND make config files easier to read. As for the comment on frontend reference I did not mention frontends so a little confused over that comment. It is true the same issue applies to bind on frontend, but I tried to keep it simple and illustrate the point with a backend example.
I’d like to configure a list of ciphers on a per backend basis
A backend have no cipher option. Do you mean the bind option ciphers ?
I don’t want to use ssl-default-server-ciphers in the global section as each backend can have a different set of ciphers.
Well then don't set ssl-default-server-ciphers and define the ciphers on the server line.
A backend have servers which have ciphers as option. Please don't mix the keywords with what you want to do.
frontend and listen => have bind option
backend have no bind option and therefore no ciphers parameter!
This is explained in the Proxies section of the documentation.
Related
I am trying to add DNS over TLS (DoT) protocol to the zgrab2 tool. I used the zgrab2 documentation but I am not able to figure it out. Has anyone added a new protocol that is not there like port 853? ZGrab2 has the common ports but not post 2015.
From my understanding, you need to write your own code for DNS over TLS (DoT) in golang,
and then run an integration test on it. I understand the latter but have no idea how to create a module for port 853.
Would appreciate any suggestions or useful links anyone has. Thanks!
We're implementing consul with TLS security enabled, but it doesn't look like the consul agent performs any revocation lookup on the incoming (or local) certificates. Is this expected behavior? We'd like to be able to lock rogue/expired agents out.
Does anything reliably implement CRL/OCSP checking? As far as I know the answer is basically no.
From what I understand, the current best practice is just to have very short-lived certs, and change them all the time. letsencrypt is good for external services, but for internal services (which you likely use consul for), Vault(done by the same guys that do consul) has a PKI backend that does exactly this. It publishes CRL if you have any tools that bother, but as far as I can tell, basically nothing does, because it's sort of broken (denial of service, huge CRL lists, slower, etc) More info on Vault here: https://www.vaultproject.io/docs/secrets/pki/index.html
Also, there are other internal CA tools, and for larger infrastructure you could even use the letsencrypt code(it is open source).
By default, Consul does not verify incoming certificates. You can enable this behavior by setting verify_incoming in your configuration:
{
"verify_incoming": true,
"verify_incoming_rpc": true,
"verify_incoming_https": true,
}
You can also tell Consul to verify outgoing connections via TLS:
{
"verify_outgoing": true,
}
In these situations, it may be necessary to set the ca_file and ca_path arguments as well.
I checked my domain in mxtoolbox and found following errors/warnings:
dmarc Missing or Invalid Record
https The Certificate is invalid
smtp Reverse DNS does not match SMTP Banner
dns At least one name server failed to respond in a timely manner
dns SOA Expire Value out of recommended range
I added a txt record in DNS zone for as "_dmarc" and checked it
nslookup -query=txt _dmarc.mydomain.com
its showing our server IP
Please advise how can I fix all these errors or warnings?
Best regards
#lifesaver That's a tall order without knowing what your domain is to evaluate.
But here's your general answers.
If you're missing a DMARC Record in DNS Add it. If it's invalid we need to know what you added
Why is the certificate invalid?
You need to make it match for smtp (Also it's a good idea to make it match for pop and imap
mxtoolbox has a small timeout window on DNS queries use a different tool
This is pretty subjective - but it's talking about the SOA TTL value in DNS is outside of their recommended range. Not sure what their recommended range is, but RFC 1912 recommends 14-28 days.
If you need answers to the questions above send an email to mailtest#unlocktheinbox.com - It will auto-respond and give you a lot more insight, to what's going on.
I am fairly new to Pound cfg and SSL in general and working on learning. Tried a few things I found on Google related to setting Ciphers but they failed.
We are having an issue with Firefox after setting Ciphers in Pound to not allow SSLv3. Firefox tells customers that the system is not setup properly, so it is blocking them. Here is what I am trying to do.
Disallow SSLv3, SSLv2 via Pound Cfg file. Here is what I have tried:
Ciphers "All:!SSLv2:!SSLv3"
We are using SHA2 through Godaddy for Cert and SHA256 for key. When I test via https://dev.ssllabs.com/ssltest/ we get a giant F. Any ideas?
Any and all help is greatly appreciated. Thanks!
"Ciphers" is used to configure the cipher suites, not the SSL/TLS protocols. According to the man page, you want to do this:
Disable SSLv3
Note that Disable works by disabling that protocol and all lesser protocols, so disabling SSLv3 also disables SSLv2 along with it.
You will probably want to configure Ciphers as well. Exactly how you configure it depends on what browsers and user agents you want to support, but you can get started with:
Ciphers: "EECDH+AESGCM:AES128+EECDH"
Why do vendors who provide FIX protocol connectivity require a static IP address? Is the only reason user identification/validation? Or is there any other reason behind that?
Thanks
Yes, the reason is that the (free registration required, sadly) FIXT specification test cases (specifically test case 1S/c) requires IP validation for Logon messages. It does not exclude the possibility of allowing an entire IP block (just references "system configuration" as a source of the allowed IP), but most vendors follow the spirit of highest possible security.
The spec (page 39) further mentions unauthorized attempts to break into your system as the reason for doing the validation.