I've written a MIDlet server that handle tcp inputstream. I send xmlhttprequest with an http:// url from a html web page and it works fine. I want to do the same with an https url.
with my secureserverconnection instancied by a connector.open the accecptandopen() method return an exception.
handshake client send
As you can see the xmlhttprequest send an handshake hello but I've notices tls1.2 protocol then tls1.0 protocol and finally tls1.2.
Is it normal having 2 different protocol sent by the client. It is the first phase of the handshake protocol.
My Midlet java server respond with an Alert and a a "ssl3_get_client_hello:no shared cipher" error (IOException)
IOexception capture
I've specified the connector options like this : cipher : TLS_RSA_WITH_AES_128_GCM_SHA256 and TLSv1.2 protocol
tlsv1.2 server response
Have someone ever done it or can explain me why the cipher handshake is in error?
Yes it is normal for the client to try both protocols. The most likely scenario is that your device simply lacks any valid certificates, since J2ME devices are so old.
See:
"ssl3_get_client_hello:no shared cipher" in server depending on server certificate and key
Related
I'm working on an academic project about TLS handshakes and i have captured some TLS traffic generated by multiple clients (google chrome, firefox...) and I want to see if for a given browser the client hello message will always be the same or no (I have removed the GREASE extensions because they are added in a random way to the client hello message and I omitted the SNI). I found that the same browser generate multiple client hello messages.
Is it normal to see such behavior or I'm doing something wrong?
A TLS handshake is done for each TCP connection involved in HTTPS and it is common that the browser uses multiple TCP connections in parallel. This is probably what you see. Multiple TLS handshakes within the same TCP connection are uncommon but might happen if a server requires a client certificate only for a specific path and thus triggers a renegotiation.
I am in a big issue regarding TLSv1.2 and unable to resolve this.
Scenario:
Hostapd should act as an integrated EAP server.I have an openwrt device on which hostapdv2.6-devel is running.
2.Wpa_Supplicant is acting as a client and should talk to hostapd for successful authentication.wpa_supplicantv2.6-devel is running on a different openwrt device.
3.Two way SSL handshake(EAP-TLS) should happen successfully and hostapd should authenticate the client device without any issue.
4.Requirement is that this communication should take place on TLSv1.2 i.e. server (hostapd)is bound to send TLSv1.2.
Configuration:
EAP server(hostapd configuration):
1.Since by default server is sending TLSv1.0 to the client so I made it to send TLSv1.2 forcefully by recompiling the package for TLSv12 and install again on the router.
2.Created a configuration file, which has all the server certificate, ca certificate chain eap_server=1 etc.
3.Started the hostapd process on the device successfully.
client configuration(wpa_supplicant):
1.Created a configuration file, which has all client certificate, CA chain, identity, SSID etc.
2.Started the wpa_supplicant on the device successfully.
SSL transactions:
1.client send client hello message and TLSv1.2 in it.
2.Server responds with server hello message and TLSv1.2
3.Server sends its certificate, serverkeyexchange, certificate request message.
4.Afterward a fatal alert occurs "decode_error" and no more transaction are seen and authentication gets failed.
Please see the wireshark capture below.
ClientHello
ServerHello
Alert Message
Kindly help me to resolve this issue as its making my life difficult.
Please let me know if any other information is required.
Thanks.
I'm having trouble blocking the use of HTTP/2 in order to force browsers to use HTTP/1 as the protocol inside https. TLS MITM is out of the question, NFQUEUE-like usermode packet filtering may be considered at most, depending on processing overhead.
From reading the ALPN RFC it's not clear if providing an alert response or dropping the connection when I see a ClientHello that contains ALPN:http/2 will make the browser retry without ALPN.
If I understand correctly, modifying the ClientHello is out of the question as it results in a checksum error when the server responds with the ServerHello because changing the ClientHello invalidates the MAC for that packet.
Is the behavior for blocked handshakes w.r.t. ALPN the same as for handling TLS version fallback, i.e. TLS_FALLBACK_SCSV ?
EDIT: according to t1_lib.c from openssl, if the server doesn't know about ALPN, it ignores it. So if the server returns Alert for a ClientHello containing ALPN, it's probably only because it doesn't support TLS1.2, there is no way to signal to the client "please retry without ALPN" other than "alert" which results in the client trying TLS1.1.
HTTP/2 over TLS is negotiated via ALPN.
Browsers will tell to servers that they support it.
If you don't want to use HTTP/2, then you just have to modify the server configuration in a way that it doesn't have h2 as one of the protocols that it can negotiate via ALPN.
The ALPN negotiation will then fall back to HTTP/1.1 and the client will use HTTP/1.1.
A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.
I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).
However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem?
In the DataPower system logs I can see below error:
Request processing failed: Connection terminated before request headers read because of the connection error occurs
Update:
The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?
I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV
This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.
The https-version of my website suddenly is not reachable any more from Firefox or Chrome (chrome shows ERR_TIMED_OUT). Both browsers behave as if the site was down. With Internet Explorer is working all right.
This happens on multiple computers since yesterday. I use a startcom.org signed certificate.
Wireshark shows:
TLSV1 Client Hello
TLSV1 Server Hello
Certificate
Server Key Exchange, Server Hello Done
Client Key Exchange, Change cipher spec, Encrypted Handshake Message
Encrypted Handshake Message, Change cipher spec, Encrypted Handshake Message
Encrypted Alert
TCP RST, ACK
A bit later there is a request from User-Agent: Microsoft-CryptoAPI/6.1 to crl.startssl.com/crt1-crl.crl
Any help appreciated.
This may be caused by different behaviour when checking for certificate revocation (via CRLs) doesn't work. It seems that StartSSL has had some problems recently, and http://crl.startssl.com/crt1-crl.crl is quite slow to respond.
You can check whether it's enabled in your browser.
In IE: Internet Options -> Advanced -> Security -> Check for server certificate revocation
In Firefox, in about:config -> see the options that contain the text crl (and ocsp).