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
Related
I am developing a desktop client application for an https-protocol based REST API provided by a third party.
I want to test the programmatic communication with the API when the server's certificate is not installed on my local computer. For this, I need to know how to make it mandatory to have the server's computer installed on my computer. Note: the certificate is not self signed, rather it is issued by a CA.
I want to test what errors enterprise users will get when my client application will make the API call to the SSL server in a highly secure enterprise environment where the IT policy is configured to mandatorily require installation of server's certificate on the client's local computer.
Is there such a configuration in Window which makes it mandatory for server certificates installed on local computer, for any API communication? If yes, can someone guide me on the steps for Windows 10 Professional.
Hey :) I’m learning about Kerberos. I first read about the MIT Kerberos and then about the uses in Microsoft. I found some difference. I just want to be sure. Is it right that in the original MIT Kerberos a hash of the password never send from the client to the server, but in Microsoft Kerberos it happened?
Huh?
Kerberos is Kerberos. It's a well defined specification and all the different implementations are more or less implemented the same. The Windows implementation certainly has it's share of quirks, but it doesn't in any way send the password hash to the server.
Kerberos uses a key agreement process to exchange messages. Both the client and KDC know the users "long term credential" which is their password hashed using a specific key derivation function. When the client wants to send a message to the KDC, it encrypts it using the long term credential. The KDC knows that credential so it can decrypt it. The response is encrypted in the same way.
Neither party sends the password or its hash to the other in general use.
There are two separate but specific scenarios where this doesn't apply however.
When using a certificate to logon via PKINIT, Windows will include the long term credential in the user PAC of the ticket (so the workstation can decrypt it), encrypted to the Diffie-Hellman derived secret.
The other scenario is when doing FIDO logon, the long term credential is included in an authorization data element.
Both of these scenarios exist to allow clients to support legacy protocols that only understand password authentication.
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.
I want to connect to my ejabberd server from another machine using a certificate instead of a login/password. I've looked for authentication client-to-server with a certificate for ejabberd, but i couldn't find something helpfull.
If anyone has any ideas how it cas be done, I'm taking..
As of version 16.02, ejabberd Community Server does not yet support client cert authentication.
However, if your questions is about communication encryption, you can indeed configure ejabberd with Starttls support to use TLS between client and server. A service like Let's encrypt can provide such certificates for free: https://letsencrypt.org/