I am using OpenShift Online Pro account , I deployed a web application using apache httpd2.4 server and I created a route with domain I purchased from AWS.
Then I add SSL certificates using letsencrypt , now when I test this router I can see tls 1.0 & 1.1 are deprecated and some list of weak ciphers and I want to remove them from this router.
How can I disable this 2 versions and remove weak Ciphers ?
Any help could be appreaciated!
In OpenShift, TLS ciphers can only be enabled / disabled on a Router basis (see documentation). This means for OpenShift Online this is most likely not possible, although I would recommend to ask Support about it.
A workaround would be to use a "passthrough" Route and to terminate TLS in your container. That way you can control what TLS versions your application / webserver is serving.
Related
i am trying to fix a security vulnerability that says application should not support TLS v1.0 and also need to disable weak ciphers .How can i achieve this ?
The web application in question is running on dedicated a tomcat 8.xx version.
I have a Ubuntu 16.04 Server and I would like to know witch version of TLS is already installed on my server.
And how to upgrade to version 1.3 if version version is under v1.3
Thank you
While you don't specify it you are probably asking about the TLS support in your web and/or mail server. For the common servers on Linux the support is implemented with OpenSSL. Since you are using Ubuntu 16.04 you by default have OpenSSL version 1.0.2 which supports TLS up to TLS 1.2. But note that configuration of the servers might cause the actual protocol support to be limited.
There is no official TLS 1.3 yet, i.e. the protocol is still not finalized. Support for TLS 1.3 is expected to be available in OpenSSL 1.1.1 which is still in development.
Sniffing the packets with some application like Wireshark would reveal the information; the protocol version used in a connection is in the ServerHello message or
use http://ssl-checker.online-domain-tools.com tool to verify
I would suggest that you use the SSL test website by Qualys. If you ran your webserver with SSLProtocol +All for just a quick test, it would tell you what SSLProtocols are being served with your pages and a recommendation on which ones should and should not be used.
On a side note, I made a recurring task to test my sites; I found something even today that had changed since I last checked 3 months ago.
https://www.ssllabs.com/ssltest/index.html
I'm a novice in regards to Transport Layer Security stuff, to bear with me...
I have some https web apps that I test locally using self-signed certs created with selfssl.exe. The company recently pushed new rules to everyone's machines that prevent the browsers from loading https sites that use anything other than TLS 1.2. However, my browsers give me certificate errors when I load my locally-hosted test stuff if TLS 1.0 is not enabled. Is it possible to generate self-signed certs that will work with my browsers if only TLS 1.2 is enabled?
I'm using Windows 7 64 bit with IIS 7.5, and I test with a variety of browsers (IE 11, Firefox 46, and Chrome 50).
No, it is not possible
SSL/TLS in all versions works with x509 digital certificates. The difference between TLS versions is the protocol rules, not the certificate.
The browser warns usually when the used protocol is old(consideres less secure) or the certificate is not trusted
Eventually figured this out. The answer is kinda dumb...
On Windows 7 / Windows Server 2008 R2, the TLS 1.2 protocol is installed, but disabled by default. When Big Brother pushed everybody to TLS 1.2, they did it with SCHANNEL registry entries, but they did not create the "DisabledByDefault" entry set to "0" so it blew up the security of all the Windows 7 users on the domain.
So, if you're going to use registry hacks to push users over to TLS 1.2, be sure to follow the instructions from Microsoft and remember to create a "DisabledByDefault" entry in the TLS 1.2 SCHANNEL key. :-)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786418(v=ws.11)
We have a legacy web application that runs in a tomcat under java 6, upgrading to 7 or 8 is infeasible as the application needs significant work to allow this and the fixes required are too large to implement in a legacy application. We now have a requirement to connect outbound (i.e. as a client) over TLS 1.2 however java 6 only supports 1.0. We use Apache as our web-server and OpenSSL for incoming connections and this happily supports TLS 1.2 etc.
Has anyone had to address a similar issue, or can you comment on the following potential work arounds:
Loopback to localhost (or otherwise redirect) and use OpenSSL to create a TLS 1.2 connection,
effectively an internal proxy
can openssl be a client?
do we need s_client?
Use our current the firewall to upgrade the connection
this would need to be selective
Obviously implementing this will depend on the firewall
Use “Bouncy Castle” (https://www.bouncycastle.org/)
Don't use openssl's s_client for this - it's slow, and intended more for debugging/testing.
Try using stunnel. It's designed for use cases like yours, and you can find plenty of example configs to get you started. You'd want to make sure to include the sslVersion = TLSv1.2 directive in your configuration to force use of TLS 1.2.
We have clients who can be using anything, WindowsXP,Vista,Linux....
Currently our systems support SSLV2 and SSLV3.But, we are planning to disable both SSLV2 and SSLV3 in windows server 2008R2 in favour of TLS 1.2.
Will it have any breaking changes with the end user?I'm worried that If I disable SSLV3 ( and SSLV2) , some of the clients who use windowsXP(for example) might not be able to access my web service.
PS: Tried to find a similar question in stackoverflow, didn't find any. So, posting this as a question. :)
This is one of the scenarios where you will NOT be able to support old clients using insecure protocols and expect to have decent security.
If you have not enabled TLS 1.2 yet, do so.
Some clients do not support TLS 1.2 (e.g., older Android versions). You may need to support TLS 1.0 and 1.1 in addition to 1.2. While not ideal, it is definitely better than supporting SSL 2.0 and 3.0.
Post an announcement indicating that your web service is being upgraded to meet minimum security requirements and set a date for retiring insecure protocols.
Optionally, check your server metrics to see what protocols/ ciphers are used. Since you haven't mentioned your web server, I'm assuming it is IIS, in which case this is not easy[1][2].
Retire SSL 2.0 and SSL 3.0. There will be a few clients who will not be able to connect. Plan to have an answer ready for them. If you have clients running XP and using IE6, they have bigger issues than not being able to access your web service.
While you are at it, run your TLS configuration through an online
scanner like SSL Labs to ensure you fix any other issues.