I am using "ssmtp" as mail client to send email to remote mail server on Ubuntu Linux. I know there are "UseTLS" and "UseSTARTTLS" options in ssmtp.conf which can make ssmtp send emails with secure. However, I don't find any option to specify the minimum TLS version so that I cannot force ssmtp to use TLSv1.2.
As we all know, TLS 1.0 is badly broken, and TLS 1.1 is damaged...
Do you have any idea about how to make TLS 1.2 be used by ssmtp by default?
While you might like to restrict the TLS version or ciphers for better security this part of the security does not matter at all at the current stage of TLS implementation in ssmtp. From a look at the source of version 2.64 the TLS support in ssmtp is very limited and it does not even make any attempts to validate the certificate of the peer. This means man in the middle attacks are trivial even if you could choose the best protocol version and cipher.
This means ssmtp is not recommended if you are serious about TLS. Nevertheless even with proper TLS support SMTP is not secure. This means for anything which really needs protection use end-to-end encryption like PGP or S/MIME.
Related
Is it possible in SSL/TLS handshake where client only send its certificate. Server need not to send any certificate ?As of now in one way handshake only server send its certificate to client.
As i am aware of that in this scenario server needs to maintain all clients root certificate(if diffrent).This is not practical.If possible what are the security concerns.
Here is context under Use of SSL with socket programming in C# or C++
Thanks for help!
Yes, it is possible to use SSL/TLS without a server certificate. See https://security.stackexchange.com/questions/38589/can-https-server-configured-without-a-server-certificate
You need software that supports at least one of the anonymous cipher suites SSL/TLS supports, such as TLS_DH_anon_WITH_AES_128_CBC_SHA256. Per the OpenSSL Diffie Hellman wiki entry:
Anonymous Diffie-Hellman uses Diffie-Hellman, but without authentication. Because the keys used in the exchange are not
authenticated, the protocol is susceptible to Man-in-the-Middle
attacks. Note: if you use this scheme, a call to
SSL_get_peer_certificate will return NULL because you have selected an
anonymous protocol. This is the only time SSL_get_peer_certificate
is allowed to return NULL under normal circumstances.
You should not use Anonymous Diffie-Hellman. You can prohibit its use
in your code by using "!ADH" in your call to SSL_set_cipher_list.
Note that support for such cipher suites and configurations in most available SSL/TLS software is either non-existent or very limited, as such configurations are vulnerable to man-in-the-middle attacks - one of the very things SSL/TLS is used to prevent. You'd have to compile your own OpenSSL code, for example.
Unless you control the software at both ends of your communication channel(s), effectively there's no way to implement such a system.
And there's no real reason to implement such a system as it's not secure at all.
But you can do it with a lot of effort.
Server Certificate which contains the public key part of its key pair is must. The client may decide to overlook the authenticity of the certificate( Its bad!) but the TLS handshake requires the public key for the generation of pre-master-secret. So no way you can prevent server from sending the certificate.
Server if it wishes can request client for its certificate. This is for authenticating the client.
I am using Ansible on a Linux computer connecting to a windows 8.1 embedded computer. It's able to connect with username and password over the HTTPS port 5986, but I need to specify the option:
ansible_winrm_server_cert_validation=ignore
The ansible documentation specifies:
The following is necessary for Python 2.7.9+ (or any older Python that
has backported SSLContext, eg, Python 2.7.5 on RHEL7) when using
default WinRM self-signed certificates:
The windows computer has an SSL listener that was configured with Self-SignedCertificates from the powershell script:
https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
My question is that if I'm ignoring server cert validation, does that compromise the encryption that HTTPS is supposed to provide? or is server cert validation just a separate process of HTTPS?
Thanks
Yes, if you ignore certificate validation as recommended in the default Ansible config for WinRM, your connection is not secure - someone can spoof the target server using a man in the middle (MITM) attack on the HTTPS connection. (There should really be a security warning in the Ansible docs.)
The best alternative seems to be NTLM/Negotiate authentication, instead of HTTPS, removing the need for an SSL certificate. Your Ansible control machine will need to be able to authenticate over NTLM as a Windows user, just like using an SMB file share.
You will need pywinrm 0.2.0 or higher for NTLM/Negotiate support.
Useful links
Why NTLM/Negotiate for WinRM - background on why it's good to avoid the complex setup to install SSL certificates by using NTLM (Ruby based but still useful)
Example Ansible setup for NTLM
More complete Ansible setup including NTLM
Certificate validation is a separate process than encryption. The communication will be encrypted. You can read more on the issues with self-signed certificates but the high level is you remove any way for Ansible to validate who exactly is on the other side of the connection an open your self to a man in the middle attack that HTTPS usually protects you from.
We are using OTRS, which receive mail through external mail provider via IMAPS.
Mail provider is going to stop supporting mail clients which use unsafe SHA-1 signing algorithm. To continue using this mail provider we must be sure that our OTRS uses exactly SHA-256 algorithm to sign certificates during IMAPS session.
How could I check, what signing algorithm is used for IMAPS? Where can i find configs for this?
OTRS: 4.0.13
OS: CentOS 7.1
Running an Exchange 2003 setup and have been asked by one of our clients to enable TLS. I understand the concept and reasoning for this. However, my question is what consequences making this change to our server will have on all other clients that don't have TLS enabled on client side? Or is this a non issue? Basically will the mail still flow in cases where TLS isn't activated?
Any insight would be appreciated.
TLS will only be enabled on the connection if both sides support it. Otherwise, in most cases, the message will be delivered in plain text, without encryption. However, there are some MTA's that are configured to abort the connection if the other side does not support TLS, or if the certificate check fails.
Currently I am using Net::LDAP::Server to setup my server but it is not secure enough.
Is there any module or method so that I can setup a LDAP server over TLS or other secure connection?
I just found many information about how to connect to a secure ldap server, but cant found how to setup a secure ldap server.
Can anyone give some advices?
How does an LDAPS connection work
LDAPS is an unofficial protocol. It is to LDAP what HTTPS is to HTTP, namely the exact same protocol (but in this case LDAPv2 or LDAPv3) running over a secured SSL ("Secure Socket Layer") connection to port 636 (by default).
Not all servers will be configured to listen for LDAPS connections, but if they do, it will commonly be on a different port from the normal plain text LDAP port.
Using LDAPS can potentially solve the vulnerabilities described above, but you should be aware that simply "using" SSL is not a magic bullet that automatically makes your system "secure".
First of all, LDAPS can solve the problem of verifying that you are connected to the correct server. When the client and server connect, they perform a special SSL 'handshake', part of which involves the server and client exchanging cryptographic keys, which are described using X.509 certificates. If the client wishes to confirm that it is connected to the correct server, all it needs to do is verify the server's certificate which is sent in the handshake. This is done in two ways:
check that the certificate is signed (trusted) by someone that you trust, and that the certificate hasn't been revoked. For instance, the server's certificate may have been signed by Verisign (www.verisign.com), and you decide that you want to trust Verisign to sign legitimate certificates.
check that the least-significant cn RDN in the server's certificate's DN is the fully-qualified hostname of the hostname that you connected to when creating the LDAPS object. For example if the server is , then the RDN to check is cn=ldap.example.com.
You can do this by using the cafile and capath options when creating a Net::LDAPS object, and by setting the verify option to 'require'.
To prevent hackers 'sniffing' passwords and other information on your connection, you also have to make sure the encryption algorithm used by the SSL connection is good enough. This is also something that gets decided by the SSL handshake - if the client and server cannot agree on an acceptable algorithm the connection is not made.
Net::LDAPS will by default use all the algorithms built into your copy of OpenSSL, except for ones considered to use "low" strength encryption, and those using export strength encryption. You can override this when you create the Net::LDAPS object using the 'ciphers' option.
Once you've made the secure connection, you should also check that the encryption algorithm that is actually being used is one that you find acceptable. Broken servers have been observed in the field which 'fail over' and give you an unencrypted connection, so you ought to check for that.
How does LDAP and TLS work
SSL is a good solution to many network security problems, but it is not a standard. The IETF corrected some defects in the SSL mechanism and published a standard called RFC 2246 which describes TLS ("Transport Layer Security"), which is simply a cleaned up and standardized version of SSL.
You can only use TLS with an LDAPv3 server. That is because the standard (RFC 2830) for LDAP and TLS requires that the normal LDAP connection (ie., on port 389) can be switched on demand from plain text into a TLS connection. The switching mechanism uses a special extended LDAP operation, and since these are not legal in LDAPv2, you can only switch to TLS on an LDAPv3 connection.
So the way you use TLS with LDAPv3 is that you create your normal LDAPv3 connection using Net::LDAP::new(), and then you perform the switch using Net::LDAP::start_tls(). The start_tls() method takes pretty much the same arguments as Net::LDAPS::new(), so check above for details.
Well, perhaps LDAPS is not an RFC but to say it is not a standard or secure is certainly a stretch.
LDAPS is supported by ALL LDAP Server Vendors.
LDAPS is at least as secure as HTTPS.
As with ALL SSL (or TLS) the security weak points are how the certificates are handled.
Certainly LDAPS is more supported by LDAP server vendors and clients than is TLS. Active Directory as one example, does not support TLS. Querying the rootDSE for the supportedExtention 1.3.6.1.4.1.1466.20037 will (should) show if TLS is supported on any particular LDAP server.
We have some examples at:
http://ldapwiki.willeke.com/wiki/Perl%20LDAP%20Samples.