I want to know is if we can handle messages handshake SSL / TLS in Java code, in other words in the query ClientKeyExchange is if we can manipulate or select the key that will be sent to the server?
Yes, if you install a KeyManager that does what you want in the SSLContext you get the socket from. See the JSSE Reference Guide.
Related
I am puzzled a bit about Postgres option sslmode=prefer. It implies that it negotiates with the server to figure out whether the server supports TLS or not.
I am curious how it's done. Does it try TLS first and if it fails, try without TLS or am I missing something in TLS (or Postgres) which allow them to truly negotiate this?
Does it try TLS first and if it fails, try without TLS
Yes. And when both attempts fail, this might be visible, as two different error messages might be produced.
Some additional info on top of #janes answer:
https://www.postgresql.org/docs/current/protocol-flow.html
To initiate an SSL-encrypted connection, the frontend initially sends
an SSLRequest message rather than a StartupMessage. The server then
responds with a single byte containing S or N, indicating that it is
willing or unwilling to perform SSL, respectively. The frontend might
close the connection at this point if it is dissatisfied with the
response. To continue after S, perform an SSL startup handshake (not
described here, part of the SSL specification) with the server. If
this is successful, continue with sending the usual StartupMessage. In
this case the StartupMessage and all subsequent data will be
SSL-encrypted. To continue after N, send the usual StartupMessage and
proceed without encryption.
Is there any other way apart from openssl/netstat to check sslv3 existence.
I am using websphere application server version 8.5.5.6, according to IBM 8.5.5.4 and later versions will have the remediation for disabling sslv3 by default. Added i just double checked using openssl and netstat to find its presence
My result received as per my expectations as
"SSL Handshake failure Exception"
but when my application goes for scan it fails and falls under the poodle attack.
My server is configured in a way that all application servers uses TLv1 and webserver uses TLSv2....
Is there anything that i should be more focused here?
Any thoughts?
I configured exim mail server on centos. It is working with no encryption type. But not with SSL and TLS. I din't get correct solution for this type of error. Can anyone tell solution and why this error message in exim main.log file?
The error message is like below in the exim main.log file.
2015-03-17 10:34:16 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=acp-node [10.7.2.137] input="\026\003\001"
(input sent without waiting for greeting) ... input="\026\003\001"
In short: You are trying to use implicit TLS on a port where explicit TLS is needed.
In detail: There are two ways to use TLS with SMTP:
implicit TLS, that is TLS from start. This is used on port 465 (smtps). This mode is in some SMTP stacks simply called "SSL".
explicit TLS, that is start with plain SMTP and upgrade to TLS with the STARTTLS command. This is used on ports 25 (smtp) and 587 (submission). This mode is in some SMTP stacks simply called "TLS".
If you look around at the questions regarding use of SMTP with TLS you will find lots of confusion about how to use these modes with the various setups. And you will find lots of bad code which tries to use implicit TLS where explicit TLS is needed.
What you see is the result of the client trying to use implicit TLS on a port not suitable for this. \026\003\001 (or hex 16 03 01) is the start of a TLS 1.0 handshake and input sent without waiting for greeting refers to the fact, that the client is sending data first without waiting for the server to send the (plain text) SMTP greeting.
Judging from the error log entry, your mail client 10.7.2.137 is trying to establish a secure (TLS) connection but your Exim server is not expecting it.
Most probably, TLS is not configured properly in your Exim configuration file. You can refer to http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html for tutorial.
The solution is, therefore, to edit your Exim configuration file, making sure TLS certificates are defined and tls_advertise_hosts is set; and then restart Exim.
Im trying to establish a TLS socket connection to chat.facebook.com port:5222 through Nodejs.
Im using the following code :
var a=require('tls');
var b=a.connect(5222,'chat.facebook.com',function(){console.log("connected");});
b.on('error',function(error){console.log(error);})
But it is not getting connected and instead giving an error :
[Error: 140089045411648:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:683:]
I have tried a similiar connection to encrypted.google.com:443 and console readily fired a "connected" .
Can someone guide me what i have been missing or what can be done to overcome this problem.
xmpp with tls uses "STARTTLS", a protocol upgrade from plaintext to encrypted. See http://xmpp.org/rfcs/rfc6120.html#tls for details.
(It means you have to send some unencrypted xml stuff first, and wait for the other end to confirm your choice to upgrade to TLS)
I use a SIP server that listens over port 5070 for SIP/TLS requests. I'm trying to trace and analyze why my dialer is not registering over the network through Wireshark.
I've edited all the needed fields in Wireshark's preferences, added the server's private key, edited the SIP TCP and TLS ports (which are 5070 not 5061), and all I'm getting now clearly is the TLS Client Hello and Server responses, but no SIP is showing up, just TCP SYNs and ACKs.
I've searched and tried everything possible, but to no avail - any help would be highly appreciated.
Thanks in advance.
//M
Is the TLS session using a cipher suite with perfect forward secrecy? If that is the case, Wireshark cannot decrypt TLS even with the server private key. Check the cipher suite selected by the server in the ServerHello message for the substring EDH or EECDH, in which case perfect forward secrecy is used. You will have do configure the cipher suites in either the client or the server to not use any EDH and EECDH suites. With OpenSSL, use a cipher suite setting of ALL:-EDH:-EECDH or similar.
With perfect forward secrecy, the client and the server will agree on a shared session key using Diffie-Hellman (DH); the server private key is only used for signing. Without perfect forward secrecy, the shared key is encrypted with the server's public key by the client, and thus can be decrypted by the server (and Wireshark) using the server's private key (assuming the server uses an RSA key).