This might be done by issuing openssl s_client -connect with -no_tls1_2 -no_tls1_1 -no_tls1 -no_ssl3 -no_ssl2 but the result seems inconclusive to me. The listener is configured with SASL/SCRAM authentication enabled, but I am not sure if Encrypt data in transit Between clients and brokers Plaintext Enabled MSK cluster setting applies to that listener or not. Another way would be to connect to it and use wireshark to investigate traffic, if data is actually encrypted or not. The fact that I do not need to specify explicitly truststore does not mean it cannot use default java truststore and actually perform one way ssl handshake, when I give it such client settings:
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
Right?
I guess I have found the answer:
Plaintext does not apply to the listener with SASL/SCRAM control method.
Related
I have a test cluster where I want to connect to ETCD pod. It does not let me because of
"error":"tls: first record does not look like a TLS handshake"
I am not sure how to implement TLS for my client. Is there a simple way to disable TLS on ETCD?
According to these docs ETCD
can be set to accept TLS traffic, non-TLS traffic, or both TLS and non-TLS traffic.
Using the auto-tls flag did not help.
I'm looking for a service online, able to simulate an expiring SSL certificate. I know about badssl.com, but that only seems to include an expired certificate. What I'm looking to do is to call an endpoint with a certificate expiring in something like 5 days. Possible?
I do not know about an online service tailored to your needs (you could also try to contact badssl.com and ask them if they would be willing to add your test case, as it may profit others too), but locally you can run openssl s_server and configure it to use any local certificate you would have created to be in the situation you need to test.
From its manual:
The s_server command implements a generic SSL/TLS server which listens for connections on a given port using SSL/TLS.
and:
s_server can be used to debug SSL clients. To accept connections from a web browser the command:
openssl s_server -accept 443 -www
can be used for example.
Otherwise, if you are outside of the world wide web world:
If a connection request is established with an SSL client and neither the -www nor the -WWW option has been used then normally any data received from the client is displayed and any key presses will be sent to the client.
(and follows a list of special keys for special operations).
I have Local Webserver that configured to use SSL connection.
The question is - would there be any handshakes if i try to open https://localhost from any browser?
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys. But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
So, does handshake really happens, but on the upper OSI level? Or it doesnt happen at all, and there are no derive key creation?
Would there be any handshakes if i try to open https://localhost from any browser?
Yes,
The "classic" SSL handshake would require public keys and certs exchange on the network level to create Derive keys.
No. It requires a certificate, and a premaster secret, and mutual negotiation of a master key from which session keys are derived. All this is irrelevant.
But if we are trying to connect to local webserver, there would be no packets required for SSL handshake (Already tested with Wireshark).
Wireshark can't see loopback packets.
So, does handshake really happens
Yes.
but on the upper OSI level?
SSL happens in the application layer of the TCP model. The OSI model does not apply to TCP/IP. TCP/IP has its own model.
Or it doesn't happen at all
It does.
and there are no derive key creation?
There is creation of a pre-master secret, a master secret, and a session key. You seem to have some misconception of this process, but again it isn't relevant.
As far as I understood, both encrypt the connection. However, SSL/TLS "forces" the mail client to encrypt the channel from the beginning. Now let's say I telnet mail.server 25 and, after the ehlo, I am presented with STARTTLS as an authentication option that the server allows me (the mail client) to use. If I choose STARTTLS does it mean that I can authenticate myself (mail client) against the server (using my digital certificate)? why and how?
I am doing as follows but I don't understand where does the client authentication part comes in:
telnet some.mail.server 25
ehlo some.mail.server
...
250-STARTTLS
...
STARTTLS
mail from: guy
rcpt to: otherGuy
data
someting
.
quit
Shouldn't I be sending the client certificate to the server? I tried this using openssl s_client -starttls smtp which actually provides a -cert and -key options to specify the certificate and private key.
So, in fact, the only disadvantage of SSL/TLS compared to STARTTLS is that since the connection is immediately encrypted, there is no way for the client to send its certificate on the same port. Only the server can send its certificate. Correct? A lot of confusion in my head... Please clarify this for me.
Both direct TLS mode and TLS upgrade using STARTTLS can use client certificates.
The only difference between these modes is that with STARTTLS you start with a plain connection and later upgrade if the server announces support for STARTTLS. A man in the middle could strip this announcement (similar to sslstrip) and thus prevent the upgrade to TLS. This is actually used in practice, see https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks.
Unfortunately MX records, which are used to announce which servers are responsible for the mail transfer, can only announce hosts and no ports and in this case the default port 25 will be used with the plain SMTP protocol. Thus you can only get TLS by using the STARTTLS command.
I'm using django-celery do connect to a RabbitMQ broker through SSL (with the BROKER_USE_SSL setting). Is there a way to:
Verify the certificate of the broker when the connection is established.
Configure a client certificate to us to establish the connection.
The RabbitMQ side is working correctly, but I don't know how to configure Celery for this and I haven't found anything in Celery's documentation either. The settings CELERY_SECURITY_KEY, CELERY_SECURITY_CERTIFICATE and CELERY_SECURITY_CERT_STORE look like they could do this, but it seems that they're only used for message signing.
kombu.Connection accepts ssl argument as a dictionary of SSL configuration (ssl=False by default). I suppose it is applicable for BROKER_USE_SSL too.
BROKER_USE_SSL={
'ca_certs': '/etc/pki/tls/certs/something.crt',
'keyfile': '/etc/something/system.key',
'certfile': '/etc/something/system.cert',
'cert_reqs': ssl.CERT_REQUIRED,
}