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.
Related
Verified AZ pg require_secure_transport = "on"
Without any ssl and no SET PGSSLMODE=require, following command in Windows' cmd succeeded:
pg_restore --format=custom -d "port=5432 host=mypg.postgres.database.azure.com user=myuser dbname=mydb" my.dump
Checking AZ's Log Analytics workspace shows
connection authorized: user=myuser database=mydb
application_name=pg_restore SSL enabled (protocol=TLSv1.3,
cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)
So how does this SSL/Secure established or it's enabled but operation isn't on SSL channel?
pg_restore is based on libpq, and follows its conventions in this area. An unset sslmode has the default behavior of 'prefer'. It first attempts to set up an SSL connection, then tries without SSL only if that first attempt fails. So 'prefer' is identical to 'require' provided the first attempt does succeed. If you want to prove that your servers setting require_secure_transport = "on" is doing something, you should try setting sslmode=disable on the client. Then you should see a failure driven by that mismatch between client and server.
In your comment you mention sslcert and sslkey. Those are used only for client certificate authentication. This is optional, unusual, and as far as I know is not even supported by Azure's hosted PostgreSQL. SSL is generally done only with a server certificate, not with a client certificate (for example, pretty much all of the web over https uses server certs only, it isn't just PostgreSQL).
By what is unusual about libpq (in the world of SSL) is that by default, the server's cert does not need to be verified. By default, the cert is just used as a way to negotiate Diffie-Hellman-like key exchange that protects you from eavesdropping but not from impersonation. If you want to verify that the server you connect to is the right one, you would need to set sslmode=verify-full, as well as configure sslrootcert. This is all controlled by the client. While the server can insist that the client use SSL, it has no way to insist that the client actually verify the server's certificate.
From my browser I want to communicate to localhost application using ssl. Here browser(which acts as client) will submit the certificate instead of localhost application(which acts as server). Can Ssl be established in this scenario? So finally it boils down to problem statement can a ssl communication be established by server validating the client certificate and client not validating the server certificate.
The SSL/TLS implementation inside the browser do not support this scenario. A server certificate is always required by the browser with SSL/TLS in order to be sure that the browser is communicating with the expected server (as specified in the URL) and not some man in the middle. Apart from that it is not clear what you want to achieve with such a setup in the first place - maybe there is a better design for your unknown use case.
i use npgsql version 2270 and i would to secure my connection passing db password NOT in cleartext and with capability to use SSL connection on a preconfigured postgresql server. My doubt is about how set the connection string with npgsql.
I tryed adding ssl=true sslmode=prefer to conn string but i have not idea about how to verify if it work.
Is sufficient for secure data transit? is string correct?
Is needed to activate ssl also on server is right?
How can i verify if data transit on ssl mode ? Thanks all.
First, SSL isn't really about encrypting your password - it's about encrypting the entire stream. If you use PostgreSQL's md5 authentication method (see your pg_hba.conf), then passwords are never transferred in cleartext regardless of whether you're using SSL or not.
To use SSL, it's better to set SSL Mode to require rather than prefer: the latter will attempt to establish an SSL connection, but will fallback to non-SSL if the server doesn't support it. require will fail the connection attempt if SSL could not be established.
Regardless, yes, you need to set up SSL on PostgreSQL, including a certificate and a private key - you can read about this in the documentation.
If the aim is only to avoid sending passwords in cleartext, using md5 (or sha256 in more recent versions) is the simplest way.
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 need to setup a cron job to run a SOAP client. The customer insists that I connect to their web service (on an https address) from an https address. They insist that if I don't their response to me can't be encrypted.
My first question is, is that true? I thought that as long as I'm connecting to their SOAP service over https, the response back would automatically be encrypted.
If that's true, how can I run a cron job to be as https? My site is on a LAMP setup with cPanel access.
Thank you in advance for your help!
Your customers statement seems to be a little bit unclear in what he/she specifically means by "... connecting from an https adress" as there isn't any notion of the term "https adress" in the specs and https URLS only seem to make sense in the context of Request-URI s given in a https request.
Given this unclarity I'm only wild guessing. Nevertheless to me it seems your clients requirements might most probably not be connected to the http protocol but rather to establishing your TLS connection.
If your client is very sensitive in respect to the security of his system - which in fact if he intends to offer RPC requests might be a very good idea - he might not want to the whole world to be able to connect an encrypted connection to his machines and rely on any secondary authentication mechanism once the connection has been established.
As most users of the public internet don't have any certificates signed by a trusted authority this feature it isn't used out in the open wild but besides server authentication the TLS handshake protocol also provides a means of client authentication via client certificates (the relevant part being section 7 in RFC 5246 here. see: https://www.rfc-editor.org/rfc/rfc5246#section-7)
While in the absence of widely used client certificates web services usually rely on establishing an encryted connection to first to authenticate users by some kind of challange response test like querying for username and password your client might want to either additionally secure access to his machines by additionally requiring a valid client certificate or even - probably not the best idea - replace a second authorization like the one already mentioned above.
Nevertheless all this are nothing but some ideas that I came along with given the riddle in your question.
Most probably the best idea might be to just ask your client what he/she meant when saying "... connecting from an https adress"