1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Precompiled binary for curl

Discussion in 'Tomato Firmware' started by Morac, Sep 28, 2012.

  1. Morac

    Morac Network Guru Member

    I'm running the tomato-E3000USB-NVRAM60K-1.28.7500.4MIPSR2-Toastman-RT-VPN build and I'm noticing that all the executables pre-compiled static for tomato from http://multics.minidns.net/tomato/PRECOMPILED-static now through Segementation faults.

    Any reason why that is? I need curl for tomato for scripts I run at Wanup. Is there somewhere else I can get that from?
     
  2. koitsu

    koitsu Network Guru Member

    This sounds like something that should be worked out with rhester72. Otherwise you should try Entware.
     
  3. Morac

    Morac Network Guru Member

    All I really need is "curl" is that available in Entware without having to jump through hoops or install or something?
     
  4. Morac

    Morac Network Guru Member

    Well I tried Entware and tried installing curl, but when I run it I get "-sh: curl: not found", which makes absolutely no sense since if I type "which curl", it returns "/opt/bin/curl"

    I'm not sure what else to try. I really need curl to work.

    Edit:

    I double checked and the original static compiled curl returns "illegal instruction", not "segmentation fault".
     
  5. lancethepants

    lancethepants Network Guru Member

    Try this curl binary I just compiled, with static ssl and zlib. There are a lot of build options when compiling, but see if this will do what you need it to.
    http://lancethepants.com/files
     
  6. Morac

    Morac Network Guru Member

    That worked. Thanks!
     
  7. Morac

    Morac Network Guru Member

    That worked. Thanks!

    The only issue I've found is that it doesn't seem to like valid certificates (gives BADCERT_CN_MISMATCH) error , but that's probably a bug in curl 7.27.0 as compared to the one I had which was 7.23.1 (that's what comes with Entware).
     
  8. koitsu

    koitsu Network Guru Member

    That error message is quite clear about what the error is: the CommonName in the certificate does not match the name of the site your client (browser, curl, etc.) is visiting. This is a requirement for SSL to work correctly. Let me make this clear: IT IS NOT A BUG IN CURL OR IN OPENSSL. The solution is to modify whatever is generating these SSL certs to use the wildcard syntax per RFC2459 or RFC2818.

    If certificate validation in curl is not desired or you just want to shut it up, use the --insecure or -k flags.

    For browsers, there's no real solution other than to make sure the CommonName matches the site you visit in your URL bar. That is just how SSL works. There is nothing you can do about it. So, whatever script/installer/whatever is generating the SSL certificate in this case is doing so in a manner that is not compatible with what the user wants (or with general home consumer routers anyway). That's the root cause. You know the open-source mantra, right? "Patches are welcome..." Heh :)

    To be able to visit https://10.0.1.1/ the CommonName needs to be 10.0.1.1. You cannot use the same certificate for, say, https://10.0.1.2/ -- you will get the CN error. The port number has no bearing on the CommonName. Welcome to SSL.
     
  9. Morac

    Morac Network Guru Member

    I'm fairly certain it is a bug, because none of my web browsers have a problem with the site (www.wd2go.com and the certificate is for *.wd2go.com). Actually curl 7.23.1 has no problems either. Only curl version 7.27.0 does. I thought that maybe the http://curl.haxx.se/ca/cacert.pem file was bad, so I exported the certificates from Firefox. It didn't make a difference.

    This has nothing to do with Tomato though so I won't get into the details of everything I've tried. PM me if you want details.
     
  10. koitsu

    koitsu Network Guru Member

    Then it sounds like an oddity in OpenSSL rather than curl, since OpenSSL is what's doing the verification. You can see what version of OpenSSL curl was compiled against (not necessarily the same as what's being used in the case of statically linked programs -- in which case you have to cross your fingers) using --version.

    I cannot reproduce the problem using curl 7.24.0 on FreeBSD, with OpenSSL 0.9.8z, for site https://www.wd2go.com/ -- I receive no OpenSSL CN error.

    However, using curl 7.23.1 and OpenSSL 1.0.1c on TomatoUSB (provided via Entware), I do receive an error:

    Code:
    root@gw:/tmp/home/root# curl https://www.wd2go.com/
    curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
    error:14090086:lib(20):func(144):reason(134)
    More details here: http://curl.haxx.se/docs/sslcerts.html
     
    curl performs SSL certificate verification by default, using a "bundle"
    of Certificate Authority (CA) public keys (CA certs). If the default
    bundle file isn't adequate, you can specify an alternate file
    using the --cacert option.
    If this HTTPS server uses a certificate signed by a CA represented in
    the bundle, the certificate verification probably failed due to a
    problem with the certificate (it might be expired, or the name might
    not match the domain name in the URL).
    If you'd like to turn off curl's verification of the certificate, use
    the -k (or --insecure) option.
     
    root@gw:/tmp/home/root# curl --version https://www.wd2go.com/
    curl 7.23.1 (mipsel-unknown-linux-gnu) libcurl/7.23.1 OpenSSL/1.0.1c zlib/1.2.7
    Protocols: file ftp ftps http https imap imaps pop3 pop3s rtsp smtp smtps tftp
    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
    
    This error is different from yours, and it indicates the lack of root certificates (CAs) installed on my router -- and sadly Entware provides no such package for those. I also cannot use --insecure to work around that, because --insecure would also result in avoidance of CN validation.

    The curl binary provided here is labelled "DNSCrypt" and does not work for me on my router, plus states it's not even statically linked:

    Code:
    root@gw:/tmp# ./curl
    
    ./curl: can't handle reloc type 0x2f
    root@gw:/tmp# file curl
    curl: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), stripped
    
    So I'm not sure how to even reproduce the problem?

    The certificate chain and certificate details for that site are obtainable via two commands:

    echo | openssl s_client -connect www.wd2go.com:443
    echo | openssl s_client -connect www.wd2go.com:443 | openssl x509 -text

    The relevant output, from FreeBSD, is shown below. I've stripped out the irrelevant portions (for example the "unable to get local certificate" error, which is completely irrelevant since the site does not require two-way SSL verification, only one-way):

    Code:
    $ echo | openssl s_client -connect www.wd2go.com:443
    ...
    Certificate chain
    0 s:/C=US/ST=CA/L=Irvine/O=Western Digital Corporation/CN=*.wd2go.com
      i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
    1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
      i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
    2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
      i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority
    ...
     
    $ echo | openssl s_client -connect www.wd2go.com:443 | openssl x509 -text
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                09:90:3d:a7:ad:2b:41:72:07:68:8c:cc:51:cb:74:9c
            Signature Algorithm: sha1WithRSAEncryption
            Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance CA-3
            Validity
                Not Before: Jan 26 00:00:00 2011 GMT
                Not After : Jan 30 23:59:59 2013 GMT
            Subject: C=US, ST=CA, L=Irvine, O=Western Digital Corporation, CN=*.wd2go.com
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                RSA Public Key: (2048 bit)
                    Modulus (2048 bit):
                        00:bb:9e:7c:41:81:d5:8e:f5:b7:77:9d:08:aa:3b:
                        6d:53:88:c9:69:55:46:a7:1b:6e:62:50:60:f0:cf:
                        9b:6a:c0:f2:a1:45:7c:83:e6:31:50:27:c1:7e:91:
                        99:50:2e:ae:d4:c0:b5:5f:7e:c6:1e:fa:c4:39:e0:
                        21:c1:aa:a2:48:87:d4:80:2c:38:80:a1:bf:df:15:
                        0f:1c:bb:71:32:a0:f4:4b:10:09:14:2b:af:dd:20:
                        4c:58:b3:79:19:58:87:b5:d7:36:ef:d3:5b:3f:10:
                        c9:21:8d:b9:3b:9d:8f:90:cd:5b:96:ed:a3:13:24:
                        62:4d:27:c6:9f:21:55:bd:81:2f:92:36:a6:02:29:
                        3a:51:6a:3e:59:39:ad:da:bf:30:49:a3:71:06:f6:
                        96:d0:46:94:a5:1f:e5:52:39:dc:85:cf:d1:79:ec:
                        1a:73:8e:74:53:d1:ee:84:c3:3b:ef:46:e1:95:40:
                        6f:bc:10:3b:91:29:05:4c:39:3e:b6:30:93:72:52:
                        73:6d:d1:9a:2c:fb:f5:09:cf:3f:5e:60:f0:c4:2a:
                        3c:f7:7f:5d:1e:b6:af:b3:ce:b8:11:c5:81:f4:f4:
                        f7:a3:76:94:8b:8a:1b:b1:b5:d5:9b:56:05:3f:aa:
                        eb:00:33:69:30:3d:0c:35:9d:1c:64:e8:b1:d7:9f:
                        bf:6d
                    Exponent: 65537 (0x10001)
            X509v3 extensions:
                X509v3 Authority Key Identifier:
                    keyid:50:EA:73:89:DB:29:FB:10:8F:9E:E5:01:20:D4:DE:79:99:48:83:F7
     
                X509v3 Subject Key Identifier:
                    05:8A:2C:5D:81:04:3B:21:06:20:A2:AF:E4:B8:9C:6A:D5:E5:2C:12
                X509v3 Subject Alternative Name:
                    DNS:*.wd2go.com
                Authority Information Access:
                    OCSP - URI:http://ocsp.digicert.com
                    CA Issuers - URI:http://cacerts.digicert.com/DigiCertHighAssuranceCA-3.crt
     
                X509v3 Key Usage: critical
                    Digital Signature, Key Encipherment
                X509v3 Basic Constraints: critical
                    CA:FALSE
                X509v3 CRL Distribution Points:
                    URI:http://crl3.digicert.com/ca3-2011a.crl
                    URI:http://crl4.digicert.com/ca3-2011a.crl
     
                X509v3 Certificate Policies:
                    Policy: 2.16.840.1.114412.1.3.0.1
                      CPS: http://www.digicert.com/ssl-cps-repository.htm
                      User Notice:
                        Explicit Text:
     
                X509v3 Extended Key Usage:
                    TLS Web Server Authentication, TLS Web Client Authentication
    
    The CommonName (CN) is indeed *.wd2go.com, so that should work fine.

    My post was in combination a reference to your post, as well as the preceding post talking about why https://10.0.1.1/ might not work. This is the problem with threads that just have craploads of people who append/tack on random issues/problems -- it becomes completely impossible to follow the thread with relevant information. Your (Morac) problem is different than leeandroong's problem.
     
  11. leandroong

    leandroong Addicted to LI Member

    @koitsu, I tested this on transmission https error and got this
    Code:
    Tomato v1.28.0000 MIPSR1-101 K26 USB AIO
    root@BTRouter2:/tmp/home/root# cd /tmp
    root@BTRouter2:/tmp# curl https://10.0.1.1:9092
    curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
    root@BTRouter2:/tmp#
    
    What can you comment?
     
  12. koitsu

    koitsu Network Guru Member

    Looks to me like whatever is on TCP port 9092 isn't SSL at all. Have you tried telnetting to that port and issuing the string GET / HTTP/1.0<press Enter once>Host: 10.0.1.1<press Enter twice> and see if you get anything back? Otherwise you need to look in daemon log files that pertains to whatever daemon is listening on TCP port 9092. I think you said this is something called "transmission".
     
  13. leandroong

    leandroong Addicted to LI Member

    @koitsu, it was actually transmission gui. Able to access w/out SSL and use ordinary http://10.0.1.1:9092. I brought this issue to trasmission developer and still waiting respond. The way I see it, it seems that optware transmission GUI is not covered by SSL.
     
  14. koitsu

    koitsu Network Guru Member

    You cannot use the same TCP port for SSL and non-SSL (meaning both protocols cannot be supported under a single TCP port). If transmission is binding TCP port 9092 to HTTP (non-SSL), then you can only speak HTTP (non-SSL) on that port. And that's what it looks like is happening. Accessing it using https will result in the error you see there.

    If the daemon claims (in its logs, etc.) to be doing SSL on TCP port 9092, then that's a bug in the program and you need to talk to the developer (has no relevancy to this thread -- see what this thread is about :) ).

    Otherwise there are two solutions for this, and only two:

    1. The daemon needs to be configured properly to listen to non-SSL on one port and SSL on another.
    2. The daemon needs to support RFC 2817, which is the protocol which allows an HTTP (non-SSL) client to negotiate and upgrade its connection from non-SSL to SSL.
     
  15. leandroong

    leandroong Addicted to LI Member

    Thanks for the info.
     
  16. Morac

    Morac Network Guru Member

    You need to grab the certificates file, available at http://curl.haxx.se/ca/cacert.pem and point to it with the --cacert command line parameter, otherwise you'll get that error. Using the --insecure option works simply because it doesn't validate that the certificate is even valid.

    I get the same error as long as the /opt directory is mounted. If I unmount the /opt directory it works, so there must be an incompatibility with the libraries in Entware and the statically compiled curl.


    For what it's worth I noticed that Curl 7.27.0 uses PolarisSSL instead of OpenSSL:

    Code:
    curl 7.23.1 (mipsel-unknown-linux-gnu) libcurl/7.23.1 OpenSSL/1.0.1c
    zlib/1.2.7
    Protocols: file ftp ftps http https imap imaps pop3 pop3s rtsp smtp smtps
    tftp
    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
     
     
    curl 7.27.0 (mipsel-unknown-linux-gnu) libcurl/7.27.0 PolarSSL/1.1.4
    zlib/1.2.7
    Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp
    smtp smtps telnet tftp
    Features: IPv6 Largefile SSL libz
    
     
  17. lancethepants

    lancethepants Network Guru Member

    Hey, been a bit since I've checked here. Yes I did compile with PolarSSL, just happened to have it handy. I'll recompile with OpenSSL and have it posted later today.
     
  18. koitsu

    koitsu Network Guru Member

    Again: the binary I downloaded is not statically linked, despite what the author says. Quoting my previous post:

    Code:
    root@gw:/tmp# file curl
    curl: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), stripped
    
    Note "dynamically linked (uses shared libs)". :)

    And further proof:

    Code:
    root@gw:/tmp# ldd curl
            libcurl.so.4 => /opt/lib/libcurl.so.4 (0x2aac0000)
            libcrypto.so.1.0.0 => /opt/lib/libcrypto.so.1.0.0 (0x2ab16000)
            libssl.so.1.0.0 => /opt/lib/libssl.so.1.0.0 (0x2ac54000)
            libz.so.1 => /opt/lib/libz.so.1 (0x2acac000)
            libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x2acd0000)
            libc.so.0 => /opt/lib/libc.so.0 (0x2acf1000)
            libdl.so.0 => /opt/lib/libdl.so.0 (0x2ada3000)
            ld-uClibc.so.0 => /opt/lib/ld-uClibc.so.0 (0x2aaa8000)
    
    Finally, the biggest piece of evidence of all:

    Code:
    root@gw:/tmp# readelf -d curl | grep RPATH
    0x0000000f (RPATH)                      Library rpath: [/opt/lib]
    
    This software is being intentionally built this way, all the way down to the -rpath parameter being passed to the linker during link-time (meaning immediately after compile). The author has intentionally intended for this binary to link against libraries in /opt/lib (and if they aren't available, fall back to standard ldconfig libraries, e.g. /lib, etc.). This is why unmounting /opt (which is not an option) "works around" the reloc type error.

    The author of this binary/build needs to become more familiar with how to build software and the underlying semantics. I've gone over this (particularly -rpath) in further detail in another post, actually.

    I don't even know what PolarSSL (not PolarisSSL) is, nor do I know why it's involved here. This is almost certainly the root cause of the mismatched CN problem -- good find.

    All of the above is even more evidence that people should stop screwing around with random binaries on the Internet built by random dudes and instead just use Entware (not Optware). It just works, because its authors have created a proper environment which all Entware-compiled binaries work with (more technical: everything in /opt is assumed to be Entware-related, because that's how the installer sets things up. Everything is a package, the packages have proper dependency lists, and all packages/binaries are linked against a standard set of libraries which do not conflict with the ones in /lib (due to the use of -rpath)).
     
  19. lancethepants

    lancethepants Network Guru Member

    I've uploaded a new binary that hopefully should work a bit better. This one should be completely statically linked. My rpath had been previous set from another project.

    For the record, I never claimed the binary to be entirely statically linked, I just said it contained static zlib and ssl libraries, nothing more. This new one should help with entware/optware conflicts. As far as the certificate issues, you'll have to let me know, never really have used this myself, just thought I'd try and help.

    edit: btw, the ldd command you're showing is not using the binary I had previously created. Mine had static zlib and polarssl, not libcrypto as shown. Make sure you put the whole path for your ldd, most likely you're looking at the entware version found from your PATH, just fyi.

    Yep, you're definately looking at entware
     
  20. lancethepants

    lancethepants Network Guru Member

    Your ldd shows.
    Code:
    ld-uClibc.so.0 => /opt/lib/ld-uClibc.so.0 (0x2aaa8000)
    is what makes it most obvious. My binary would show.
    Code:
    ld-uClibc.so.0 => /usr/lib/ld-uClibc.so.0 (0x2aaa8000)
    or something to that extent.

    Kind of embarrassing when you really think about it.
     
  21. koitsu

    koitsu Network Guru Member

    Thanks for clarifying about the static linking, lance. Your explanation on that point makes a lot more sense.

    The curl binary I was testing/using came from here. I see that directory is now completely gone.

    Edit #1: about ldd: it looks like I WASN'T using the Entware version of ldd. There is a version of ldd that is included in Busybox which is a complete pile of crap. It's not a binary either (meaning you won't find it anywhere on a filesystem): it's built-in to the Busybox shell itself from what I can tell. Take a look at this nonsense:

    Code:
    root@gw:/tmp# ldd curl
            libcurl.so.4 => /opt/lib/libcurl.so.4 (0x2aac0000)
            libcrypto.so.1.0.0 => /opt/lib/libcrypto.so.1.0.0 (0x2ab16000)
            libssl.so.1.0.0 => /opt/lib/libssl.so.1.0.0 (0x2ac54000)
            libz.so.1 => /opt/lib/libz.so.1 (0x2acac000)
            libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x2acd0000)
            libc.so.0 => /opt/lib/libc.so.0 (0x2acf1000)
            libdl.so.0 => /opt/lib/libdl.so.0 (0x2ada3000)
            ld-uClibc.so.0 => /opt/lib/ld-uClibc.so.0 (0x2aaa8000)
    root@gw:/tmp# ldd ./curl
    curl: try 'curl --help' or 'curl --manual' for more information
    root@gw:/tmp# /opt/bin/ldd curl
            not a dynamic executable
    root@gw:/tmp# /opt/bin/ldd ./curl
            not a dynamic executable
    
    The /opt/bin/ldd binary I have (Entware) works properly, while the builtin Busybox crap is just horribly wrong.

    As for the lack of root CAs -- yep, that's not your problem/fault in the least bit.

    Edit #2: latest curl binary from here appears to "sort of" work. This one appears to be statically linked entirely (vs. dynamically linked), thus there is no RPATH ELF header string:

    Code:
    root@gw:/tmp# ./curl --version
    curl 7.27.0 (mipsel-unknown-linux-gnu) libcurl/7.27.0 OpenSSL/1.0.1c zlib/1.2.7
    Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
     
    root@gw:/tmp# file ./curl
    ./curl: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
     
    root@gw:/tmp# ls -l curl
    -rwxr-xr-x    1 root    root      1713084 Oct  4 12:41 curl
     
    root@gw:/tmp# readelf -d ./curl | grep -i RPATH
    root@gw:/tmp#
     
    root@gw:/tmp# md5sum ./curl
    90176a73f4fafbdb22149006ab7e95d3  ./curl
    
    On the other hand, when its used:

    Code:
    root@gw:/tmp# ./curl https://www.wd2go.com/
    curl: (77) error setting certificate verify locations:
      CAfile: /etc/ssl/certs/ca-certificates.crt
      CApath: none
    
    Looks fine/acceptable (I don't have the root CAs installed), but when using --insecure (-k), oddities begin:

    Code:
    root@gw:/tmp# ./curl -k -v https://www.wd2go.com/
    * About to connect() to www.wd2go.com port 443 (#0)
    *  Trying 198.107.148.110...
    * connected
    * Connected to www.wd2go.com (198.107.148.110) port 443 (#0)
    * error setting certificate verify locations, continuing anyway:
    *  CAfile: /etc/ssl/certs/ca-certificates.crt
      CApath: none
    * SSLv3, TLS handshake, Client hello (1):
     
    {binary does nothing from this point forward; have to Ctrl-C it}
    
    Some investigation work shows the process is sleeping (?!):

    Code:
    root@gw:/tmp/home/root# cat /proc/3408/status
    Name:  curl
    State:  S (sleeping)
    SleepAVG:      98%
    Tgid:  3408
    Pid:    3408
    PPid:  3349
    TracerPid:      0
    Uid:    0      0      0      0
    Gid:    0      0      0      0
    FDSize: 32
    Groups: 0
    VmPeak:    1964 kB
    VmSize:    1964 kB
    VmLck:        0 kB
    VmHWM:      968 kB
    VmRSS:      968 kB
    VmData:      200 kB
    VmStk:        84 kB
    VmExe:      1576 kB
    VmLib:        0 kB
    VmPTE:        8 kB
    Threads:        1
    SigQ:  0/1023
    SigPnd: 00000000000000000000000000000000
    ShdPnd: 00000000000000000000000000000000
    SigBlk: 00000000000000000000000000000000
    SigIgn: 00000000000000000000000000000000
    SigCgt: 00000000000000000000000000000000
    CapInh: 0000000000000000
    CapPrm: 00000000fffffeff
    CapEff: 00000000fffffeff
    
    Entware version works just fine to the same URL.

    Edit #3: I see why it's sleeping -- it's waiting for socket I/O that isn't coming. I waited until the internal curl timeout hit, and this is what resulted:

    Code:
    root@gw:/tmp# ./curl -k -v https://www.wd2go.com/
    * About to connect() to www.wd2go.com port 443 (#0)
    *  Trying 198.107.148.110...
    * connected
    * Connected to www.wd2go.com (198.107.148.110) port 443 (#0)
    * error setting certificate verify locations, continuing anyway:
    *  CAfile: /etc/ssl/certs/ca-certificates.crt
      CApath: none
    * SSLv3, TLS handshake, Client hello (1):
    {very long delay here}
    * Unknown SSL protocol error in connection to www.wd2go.com:443
    * Closing connection #0
    curl: (35) Unknown SSL protocol error in connection to www.wd2go.com:443
    
    We should probably start a separate thread for this problem and stop hijacking Toastman's release build thread; none of this has anything to do with his firmware.
     
  22. lancethepants

    lancethepants Network Guru Member

    This seems to do the trick

    Code:
    ./curl -k -v -3 https://www.wd2go.com/
    
     
  23. koitsu

    koitsu Network Guru Member

    Hm, that's strange; why would you need to force the protocol version to SSLv3 when it's already chosen as the default? See the line "* SSLv3, TLS handshake, Client hello (1):" in my output. Odd. THAT could be a curl bug. :)
     

Share This Page