What are the implications of checking one or both useSSL and useTLS boxes for LDAP config? - ssl

Adobe documentation for AEM 6 says
"Check the Use SSL or Use TLS checkboxes when configuring the LDAP
Identity Provider."
What protocol will be used if I check both boxes? Does TLS override the SSL config option? It seems to work with one or both checked, but I can't verify which protocol was used. Is checking just TLS sufficient to ensure I have a connection using the TLS protocol?

There are 2 ways to secure LDAP connections :
One is to connect to the LDAPS port (636 by default) using SSL (or
the later TLS versions). This is the legacy and non-standard way to
do it, also generally known as "Use SSL".
One is to connect to the LDAP port (389), and then enable TLS using
the LDAP StartTLS extended operation (which negotiates SSLv3 or TLS
protocols). It is generally known as "Use TLS".
The underlying version of the protocol used (SSLv3, TLSv1.0, TLSv1.1...) depends on the settings of the LDAP server or the LDAP client library.
I hope this helps.

Related

Turn on TLS 1.2

I just received an email from Authorize.net informing that they deactivate connections to their server using TLS1.0 and TLS1.1.
Question are Godaddy SSL and Web Host set for TLS1.2 connections and is there anything need to change for configure TLS1.2 for my site?
How to check which TLS use in my website?
How to check which TLS use in my website?
Use Qualys SSL Labs vulnerability tester to check which TLS version you are using: https://www.ssllabs.com/ssltest/
You may certainly see that you support several versions (this is the most common case).
Question are Godaddy SSL and Web Host set for TLS1.2 connections and is there anything need to change for configure TLS1.2 for my site?
You have nothing to do, web hosting services by GoDaddy are already supporting TLS 1.2 connections (and TLS 1.0 and TLS 1.1 - they do not support SSL v3 nor SSL v2 anymore, and it's a good thing).

WebSphere Multiple SSL Version Support

I'm running a web application that communicates with various APIs. One API requires TLSv1.2 while another will not support something that current (TLSv1 or TLSv1.1).
Does Websphere support multiple SSL versions?
I've found documentation about successfully changing the version of SSL, however I really need to be able to run TLSv1.1 and 1.2 together (if that's even possible) or run one version for one application while another for another application.
According to documentation for setting up SSL in WebSphere, to support the use of TLS 1.0, 1.1 and 1.2, I need to enable SSL_TLSv2:
Question: WAS is act SSL client, What does remote SSL server support
only TLSv1.0 or TLSv1.1 and Similar WAS is act SSL Server, What does
Remote SSL client does support only TLSv1.0 or TLSv1.1 or TLSv1.2.
What to do in order to work such environments?
Answer: There is an alternative option, SSL_TLSv2, which will enable
support for TLSv1.0, TLSv1.1, and TLSv1.2 in the environment. Please
use this setting SSL_TLSv2 in environments where support for multiple
TLS protocols is required, or if you are not sure whether your WAS
environment interacts with other servers or clients using non-TLSv1.2
protocols then, you can configure WAS to use SSL_TLSv2 using same
steps as given in the above.
Note:
Without poddle fix and configured WAS to use SSL_TLSv2
SSL_TLSv2 ==> Enables all SSL v3.0 and TLS v1.0, v1.1 and v1.2
protocols. Accepts SSLv3 or TLSv1 hello encapsulated in an SSLv2
format hello.
If you installed Poddle fix (will disable SSLv3 ) and configured WAS
to use SSL_TLSv2
SSL_TLSv2 ==> Enables these three TLS v1.0, v1.1 and v1.2 protocols.
So, changing the QoS settings to SSL_TLSv2 allows SSL Handshakes to multiple TLS versions when required.

What TLS method is better for port 587?

What is suggested method for securing submission port 587 on SMTP server,
STARTTLS command or direct TLS layer?
I am currently tend to use (mandatory) STARTTLS command and not direct TLS layer. In case of problems, STARTTLS command can be disabled without changing MUA`s configuration. I think in case of direct usage of TLS layer it would not be so straightforward.
Are there any other suggestions, opinions ? I didn't find out if it is standardised in some RFC.
You don't have a choice. Port 587 is always the STARTTLS command. The only standard port allowing an SSL-wrapped ("direct TLS") connection is port 465.
RFC 4409 talks only about plain text communication with optional STARTTLS command submission port 587.
Ignoring the other SSL/TLS security issues, the important thing is to ensure protection to SSL/TLS stripping attack.
If MUA is configured to connect to port 587 with STARTTLS, it must refuse connection when MITM attacker strips the EHLO command STARTTLS.
If server is configured to use SSL/TLS-wrapped SMTP layer and client configured to use wrapped layer, again MUA client must refuse connection when MITM attacker strips whole SSL/TLS layer.
From a security point of view there is no difference between these two approaches.
Nevertheless, it is generally advisable to respect RFC and use STARTTLS on port 587.

SSL to TLS switch - httpd RHEL 5.11

I am planning to disable SSL protocol in my site and moving to the TLS secure protocol. I will be making the configuration change in httpd. Does it require any changes to the server and client certificates or credentials which are already in place?
No it doesn't. Only the supportedProtocols needs to change.

OpenSSL let the server and client negotiate the method

Following a really outdated tutorial I managed to create an HTTPS server using OpenSSL with TLS1.2, and I'm very proud of it ;)
However TLS 1.2 is only supported in latest browsers and I would like to have some kind of negotiation of the protocol between the client and server, which I'm sure it can be done, but I'm not able to find how! So that if the client only supports TLS1.0, well use that. And if it only supports SSLv3, use that. Not sure about SSLv2, maybe better leave that...
The code I use right now is:
SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
ssl_method = TLSv1_2_server_method();
ssl_ctx = SSL_CTX_new(ssl_method);
Then the server certificates are loaded and the ssl_ctx is shared among all connections. When a client is accepted by the server socket it is encapsulated in an SSL object (whatever it represents):
ssl = SSL_new(ssl_ctx);
SSL_set_fd(ssl, client_socket);
SSL_accept(ssl);
So I guess that something has to be changed in the ssl_ctx creation to allow more methods... Any idea?
<rant> No decent, extensive documentation can be found for OpenSSL, the best available is a 10 years old tutorial! </rant>
Thanks in advance.
You do this by using SSLv23_method() (and friends) instead of a specific method (e.g. TLSv1_2_server_method() in your example). This sends the SSLv2 ClientHello but also specifies the highest protocol supported. The somewhat outdated man page says:
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand
the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
client hello messages and will indicate that it also understands SSLv3
and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client
hello messages. This is the best choice when compatibility is a
concern.
This online man page doesn't discuss the newer TLSv1_1 and TLSv1_2 protocols, but I verified in the 1.0.1g source of s23_clnt.c that SSLv23_method() includes them.
You then limit the protocols you actually accept with SSL_CTX_set_options():
The list of protocols available can later be limited using the
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these
options it is possible to choose e.g. SSLv23_server_method() and be
able to negotiate with all possible clients, but to only allow newer
protocols like SSLv3 or TLSv1.
Note, however, that you can't enable arbitrary sets of protocols, only contiguous protocols in SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2. For example, you can't choose only SSLv3 and TLSv1_1, omitting TLSv1. This comment in the source explains why:
SSL_OP_NO_X disables all protocols above X if there are some protocols below X enabled. This is required in order to maintain "version capability" vector contiguous. So that if application wants to disable TLS1.0 in favour of TLS1>=1, it would be insufficient to pass SSL_NO_TLSv1, the answer is SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2.