I want to disable SSLv3 protocol in Apache ActiveMQ.
Can not find relevant information here:
http://activemq.apache.org/ssl-transport-reference.html
The link above only shows how to configure CipherSuites
There is an enabledProtocols option you can use on the transport connector. You can't exclude, but you can choose valid protocols.
transport.enabledProtocols=<comma separated list of SSL/TLS protocols>
So, a TLS only "default" transport connector should look like this:
<transportConnector name="ssl" uri="ssl://0.0.0.0:61618?transport.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2&maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
Related
I am currently implementing OpenSSL's TLS/SSL standards into my mail service, allowing my users to select the TLS/SSL version they want. Here is the list of versions:
["TLSv1","TLSv1_server","TLSv1_client","SSLv3","SSLv3_server","SSLv3_client","SSLv23","SSLv23_server","SSLv23_client","TLS","TLSv1_1_server","TLSv1_1_client","TLSv1_1","TLSv1_2","TLSv1_2_server","TLSv1_2_client"]
I did some Googling on what the difference of the options are, and I understand that some versions are deprecated, or shouldn't be used because of security issues, such as TLSv1. I don't understand the difference between the client vs server ones, but from my own testing, the server options return errors when trying to send a mail with it.
So my question is - of that list, what should I remove?
What you show are not SSL/TLS versions but various types of SSL contexts which also include the usable SSL/TLS versions. This means the *_server "versions" are all SSL contexts which should be used on the server side where you usually also need a certificate. The *_client variants are for the client side of the TLS handshake, i.e. the one which initiates the TLS handshake.
Within a mail client you don't want to use any server specific SSL contexts because with these the mail client would expect the peer to start with the TLS handshake which it does not.
For more details see the man page of SSL_CTX_new which has a detailed description of what all these different contexts mean.
... allowing my users to select the TLS/SSL version they want.
While your specific implementation is wrong the idea of letting users chose the protocol version is wrong too. Instead you should just use a generic context without limitations (apart from disabling insecure versions) so that it automatically picks the best protocol version during the TLS exchange. Selecting specific protocol versions should only be done in case the peers TLS stack is broken, like for stacks which simply refuse a TLS 1.2 handshake instead of replying with TLS 1.0 in case they don't support TLS 1.2.
I am wondering if it is possible to implement something like mutual handshake authorization between logstash and logstash-forwarder?
At the moment, I know that logstash provides ssl certificates
for security, but I am not sure if this is the best way to protect my logs flow.
The certificates are not safe enough in my case. If they will get stolen then you are in danger.. Looking for something else that may help. Thanks!
The Logstash forwarder project has been deprecated in favor of the Filebeat project.
Generally, you should now prefer using Filebeat over Logstash forwarder. Moreover, Filebeat allows you to set up TLS client authentication, which is what you're after.
Well, seems like I was looking for mutual authentication between LSF (or FileBeat) and Logstash.
Here is what I found - there is an open issue, while it is opened, the problem is not solved.
Here is some discussion on this topic:
filebeat has same support as logstash-forwarder used to have, plus some more fine-grained TLS configs (e.g. choose TLS version or configure ciphers). Connection can encrypted via TLS + server certificated is validated. Filebeat itself supports TLS client-auth, BUT logstash must enforce (ask for certificate) client authentication, which is not implemented yet (see github issue).
I am currently seeing a vulneribility post scanning for Downgrade Prevention Attack on my website, I did a quick check on google and figured out TLS Fallback Signaling Cipher Suite Value (SCSV) can be used for Preventing Protocol Downgrade Attacks,
But can anyone suggest what changes will i have to make to my IBM HTTP server conf files to prevent this vulneribilty. If not how can we implement TLS Fallback Signaling Cipher Suite Value (SCSV)
djrecker.
IHS doesn't support SCSV, which is a protocol that enables browsers to do slightly less unsafe non-TLS negotiation when they see connections abruptly closed.
You could disable SSLv3 so there is no "weak" protocol to allow this to downgrade to.
How can I identify the cipher strength of an active https connection to a linux redhat apache webserver. I want to harden my web server by removing lower strength ciphers and would like to check if clients are even using them.
EDIT
My goal is to avoid negative impact of removal of a lower security cipher that a client relies on. Worst case scenario there is a stupid non browser (or old browser) app that is using an old insecure cipher, when I disallow the use of this cipher his/her app could break. I'm trying to proactively identify if there are any apps/browsers using any of the ciphers I'm going to disable.
You can identify unsuccessful handshakes by enabling the appropriate level of logging on mod_ssl. See the Custom Log Formats section on http://httpd.apache.org/docs/2.2/mod/mod_ssl.html, notably
CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
This should enable you to make a list of ciphers requested by clients and configure Apache accordingly.
Your question and your goal aren't necessarily related. Each active connection may use a difference cipher based on the combination of: (a) the capabilities on the server (b) the capabilities of the client (c) cipher preference of the server and client. Looking at any individual connection will not tell you if your SSL configuration is optimal.
If your goal is to harden your SSL configuration, I suggest you use
the SSL Server Test from SSL labs. It grades your server configuration based on known SSL vulnerabilities and best practices.
The last time I updated my SSL configuration I used the configuration tips from this blog post. Note that understanding of SSL vulnerabilities is constantly changing so I suggest you rerun the test every once in a while to ensure your configuration is the best that is currently known.
I received this error when my server was scanned for PCI compliance. I was wondering if it may be because I shut off iptables. I do not want to ask them to scan it again until I am sure that it will pass. My first question is, is there any way to scan for this myself? My other question is, does iptables being turned off the actual problem?
Below are just a few errors I am getting:
TCP 443 https - The remote service supports the use of weak SSL ciphers
TCP 465 urd - The remote service accepts connections encrypted using SSL 2.0
TCP 993 imaps - The remote services encrypts traffic using a protocol with known weaknesses
TCP 995 pop3s - The remote service accepts connections encrypted using SSL 2.0
Thanks for your time.
The errors are not specifically anything to do with iptables - they are indicating that the highlighted services are configured to support SSL in a weak or insecure manner.
However, if you do not intend to provide mail services to the outside world, then you should be disabling the SMTPS, IMAPS and POP3S services running on ports 465, 993 and 995 respectively (or blocking them with iptables).
In addition, presuming that you do intend to provide HTTPS services, you will need to fix the SSL configuration of the web server that you have listening. You will want to configure it to support only TLS 1.0 connections, and only strong ciphers. For help with this, ServerFault is the right site.
If you are using Apache you need to adjust some settings in your ssl.conf file. The important ones are SSLProtocol and SSLCipherSuite. The following settings worked for me but YMMV. You may need to add these to the VirtualHost container for your site and not simply adjust the existing ones in the default container.
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:!MEDIUM:+HIGH
Try these and then use one of the scanning tools below to do a free scans to see what ciphers your site is making available...
https://www.ssllabs.com/ssldb/index.html
http://www.serversniff.net/content.php?do=ssl
http://www.sslshopper.com/ssl-checker.html