Hi Thomas, The host is an amazon ec2 instance. nslookup returns: ==== $ nslookup 10.x.x.x Server: 172.z.z.z Address: 172.z.z.z#53
Non-authoritative answer: x.x.x.10.in-addr.arpa name = ip-10-x-x-x.ec2.internal. Authoritative answers can be found from: ==== That's it. I've been researching more and I'm staring to suspect it's this issue: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1006776 But I haven't confirmed that yet. Run into that bug before? And while I'm asking, do you know how to enable jvm security debugging so I could see if one of the Sun security classes is throwing an exception? Thanks, Colin On Wed, Jun 19, 2013 at 8:01 AM, Thomas Becker <[email protected]> wrote: > Colin, what happens if you do a reverse lookup of the external ip address of > the host you're running the curl and jetty server on? > > nslookup x.x.x.x > > I'm asking as you might be hitting a bug we fixed recently where jetty does > a reverse lookup of the client's ip address when establishing an ssl > connection. > > Am 6/19/13 3:03 AM, schrieb Colin Ingarfield: >> >> Hello, >> >> This might be more of an SSL/TLS question than a jetty one, but I'm >> hoping somewhere here can help me understand this. >> >> I noticed when using curl to make an https request to my application >> (uses embedded jetty 8.1.3.v20120416) it would "stall" during the TLS >> handshake and eventually time out. Example: >> >> curl -kv https://localhost:8443/some/url >> * About to connect() to localhost port 8443 (#0) >> * Trying 127.0.0.1... connected >> * Connected to localhost (127.0.0.1) port 8443 (#0) >> * successfully set certificate verify locations: >> * CAfile: none >> CApath: /etc/ssl/certs >> * SSLv3, TLS handshake, Client hello (1): >> << stalls here, timeout, followed by: >> >> * Unknown SSL protocol error in connection to localhost:8443 >> * Closing connection #0 >> curl: (35) Unknown SSL protocol error in connection to localhost:8443 >> >> Searching around I found that you can specify to curl which version of >> SSL or TLS to use when connecting via https. So when I try with TLSv1 >> (--tlsv1 switch) I get the same result as above. But when I specify >> SSL3 (--sslv3) it works as expected: >> >> curl --sslv3 -kv https://localhost:8443/some/url >> * About to connect() to localhost port 8443 (#0) >> * Trying 127.0.0.1... connected >> * Connected to localhost (127.0.0.1) port 8443 (#0) >> * successfully set certificate verify locations: >> * CAfile: none >> CApath: /etc/ssl/certs >> * SSLv3, TLS handshake, Client hello (1): >> * SSLv3, TLS handshake, Server hello (2): >> * SSLv3, TLS handshake, CERT (11): >> * SSLv3, TLS handshake, Server key exchange (12): >> * SSLv3, TLS handshake, Server finished (14): >> * SSLv3, TLS handshake, Client key exchange (16): >> * SSLv3, TLS change cipher, Client hello (1): >> * SSLv3, TLS handshake, Finished (20): >> * SSLv3, TLS change cipher, Client hello (1): >> * SSLv3, TLS handshake, Finished (20): >> * SSL connection using ECDHE-RSA-AES256-SHA >> * Server certificate: >> * subject: <CERT_STUFF> >> * start date: 2011-11-03 00:00:00 GMT >> * expire date: 2012-11-02 23:59:59 GMT >> * common name: XXXX.com (does not match 'localhost') >> * issuer: <ISSUER_STUFF> >> * SSL certificate verify result: certificate has expired (10), >> continuing anyway. >>> >>> GET /some/url HTTP/1.1 >>> User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 >>> OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3 >>> Host: localhost:8443 >>> Accept: */* >>> >> < HTTP/1.1 302 Found >> <http response...> >> >> /usr/bin/java -version >> java version "1.7.0_15" >> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~11.10) >> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) >> >> curl --version >> curl 7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e >> zlib/1.2.3.4 libidn/1.22 librtmp/2.3 >> Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 >> pop3s rtmp rtsp smtp smtps telnet tftp >> Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz >> >> Our application uses an embedded Jetty instance ver 8.1.3.v20120416. >> >> Can anyone shed some light on this? Can jetty be configured to be >> more permissive (eg, accept both sslv3 & tlsv1), or is all the SSL >> stuff dependent upon the JVM and OpenSSL libs? Any guidance greatly >> appreciated. >> >> Thanks, >> Colin >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
