Jeffrey Walton | 31 Aug 01:06 2015
Picon

Re: Why is cURL experiencing "SSL certificate problem: unable to get local issuer certificate" when the CA is available?

> cURL has access to "DigiCert High Assurance EV Root CA":
>
>      $ cat /usr/share/curl/ca-bundle.crt | grep "DigiCert High
> Assurance EV Root CA"
>      DigiCert High Assurance EV Root CA
>
> Why is cURL experiencing "SSL certificate problem: unable to get local
> issuer certificate" when the CA is available?

When I extract "DigiCert High Assurance EV Root CA" by hand and use it
manually via -CAfile, it verifies correctly.

**********

$ openssl s_client -connect github.com:443 -tls1 -CAfile
~/DigiCert-High-Assurance-EV-Root-CA.pem
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
SHA2 Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US,
jurisdictionST = Delaware, serialNumber = 5157550, street = 548 4th
Street, postalCode = 94107, C = US, ST = California, L = San
Francisco, O = "GitHub, Inc.", CN = github.com
verify return:1
---
Certificate chain
(Continue reading)

Daniel Stenberg | 30 Aug 00:08 2015
Picon

A small nudge to fix a frequent -X misuse?

Hey friends!

I see lots and lots of curl suggestions and examples on the internet use -X 
where it isn't needed. Like -XGET for an ordinary URL or using -d data -XPOST 
and so on. Just superfluous uses of -X that annoy me (possibly slightly more 
than I can really motivate).

I wanted to see if anyone has opinions about a patch similar to the attached 
one. It will cause a warning get output if a pointless -X is used, to help the 
user figure this out. I also took the change to warn for -XHEAD as that will 
most likely cause a hanging connection in most cases.

Example outputs:

$ curl -XPOST -dmoo localhost
Warning: Superfluous use of -X. --request, POST is already inferred.
[operation continues]

$ curl -XGET localhost
Warning: Superfluous use of -X. --request, GET is already inferred.
[operation continues]

$ curl -XHEAD -I localhost
Warning: Superfluous use of -X. --request, HEAD is already inferred.
[operation continues]

$ curl -XHEAD localhost
Warning: Setting custom HTTP method to HEAD may not work the way you want.

Thoughts?
(Continue reading)

David Niklas | 22 Aug 15:44 2015
Picon

Re: curl-users Digest, Vol 120, Issue 6

> <snip>
>
> So, I'm a bit stuck in a tough place. The previous behavior surprised
> a set of users and so does the new. Further, I could possibly make
> non-2xx codes not store zero byte files, but should -o behavior
> really care about HTTP response codes and won't that just be even
> harder to explain and for users to figure out?
>
> I hesitate to even suggest it (because of the option bloat we
> already suffer 
> from), but does it need another command line option to get this
> solved for both sets of use cases?
>
> I could really use some fresh ideas and opinions. Especially if you
> use one of these versions! Tell me what you think!
> 

Seems to me that looking at the return from curl:
echo $?
should be enough to tell the user whether or not the file should be
zero bytes; that's what I do. At fist, a user might become
incredulous, esp if their browser downloads a very large file, just
someone misunderstanding how the web works, and they could really
benefit from the experience, often I find that I need
to add -L to curls command line.
As you pointed out, there is no one solution for both parties, so, why
try to hide this from the user, gates ordered you to?

David
-------------------------------------------------------------------
(Continue reading)

Csányi Pál | 24 Aug 20:53 2015
Picon

Re: Updating dynamic IP address with curl

2015-08-24 20:50 GMT+02:00 Gisle Vanem <gvanem <at> yahoo.no>:
> Csányi Pál wrote:
>
>>> I don't know about cron, but you can put something like this in
>>> your ~./netrc:
>>
>>
>> Did you mean in my ~/.curlrc file?
>
>
> No, the ~./netrc. Create one if you don't have one.
>
>> The eth0 NIC is the WAN interface. It get it's IP address from my ISP.
>> eth0 is connectoed to my cable modem and cable modem to my ISP.
>> eth0 gets it's IP address dynamically: it gets a dynamic IP address.
>
>
> Okay. So if you go to:
>   http://whatismyipaddress.com/ip-lookup
>
> That address is the same as ifconfig shows?

Yes, the both address are same.

--
Best, Pali

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
(Continue reading)

Csányi Pál | 24 Aug 19:16 2015
Picon

Updating dynamic IP address with curl

Hi,

I want to use following command with curl:
http://[USERNAME]:[PASSWORD] <at> update.ipdns.hu/update?hostname=[DOMAIN]&myip=[IP]

So the command could be eg.
curl -v http://username-gmail-com:password <at> update.ipdns.hu/update?hostname=somename.ipdns.hu&myip=95.85.***.***

My question is: can one use this command as a cron job to execute
every say 10 minutes but so so the current IP address of the eth0
network interface should be substituted automatically into this
command at ..myip=CurrentIPaddress?

--

-- 
Best, Pali
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Daniel Stenberg | 21 Aug 00:14 2015
Picon

zero bytes transfers and issue #382

Hi friends!

In curl 7.42.0 we made curl capable of "transfering" zero byte files. It 
basically means that it actually creates a zero byte file when you do

  $ curl [URL] -o output

... and the URL successfully returns a file with no content. This was one of 
those silly things we've carried with us since forever and came out of the 
fact that the code for -o that writes data only ever opened the file and wrote 
something when data arrived and for a zero byte file of course no data came.

So, commit 261a0fedc brought this feature.

I've since realized that this introduced some interesting side-effects that 
surprise users. Now suddenly all those users who got a zero byte file back and 
were _happy_ with that gets an empty file that they don't need. Like when you 
do:

  $ curl -H "If-None-Match: blala" [URL] -o output

... or other variations of HTTP that gets a HTTP error response back with no 
body. This breaks scripts that previously could just check if 'output' was 
created to see if curl actually got something or not.

So, I'm a bit stuck in a tough place. The previous behavior surprised a set of 
users and so does the new. Further, I could possibly make non-2xx codes 
not store zero byte files, but should -o behavior really care about HTTP 
response codes and won't that just be even harder to explain and for users to 
figure out?
(Continue reading)

Lenny Markus via curl-users | 19 Aug 19:05 2015
Picon

Unable to connect to TLSv1.2 host

This is a continuation of the thread I started here:

TL;DR:
I'm unable to establish a TLSv1.2 connection from a specific machine, and I'm trying to troubleshoot why.

Per the suggestions on that thread, I upgraded to the latest curl/libcurl/openssl,  when that failed, I proceeded to do wireshark captures.

I don't want to blame firewall issues right away, since I can manually connect from the same box using openssl s_client

I have two captures here, 1) Failed with curl, 2) Success with openssl s_client.

This is going beyond my ability to troubleshoot, so any help would be greatly appreciated

Capture 1: This is a failed capture from calling `curl -v https://ms136.slack-msgs.com`

Capture file:

curl output:
* Rebuilt URL to: https://ms136.slack-msgs.com/
*   Trying 54.175.159.82...
* Connected to ms136.slack-msgs.com (54.175.159.82) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4: <at> STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to ms136.slack-msgs.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to ms136.slack-msgs.com:443

Capture 2: This is a successful capture from the same machine, using `openssl s_client -connect ms136.slack-msgs.com:443` and manually entering the following sequence to emulate what curl would do:
```
GET / HTTP/1.1
Host: ms136.slack-msgs.com
User-Agent: curl/7.44.0
Accept: */*
```
Capture file:

OpenSSL output:
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Slack Technologies, Inc.", CN = *.slack-msgs.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Slack Technologies, Inc./CN=*.slack-msgs.com
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE+jCCA+KgAwIBAgIQVtr0TXq3eGAn3OTB9AXfNjANBgkqhkiG9w0BAQsFADBE
MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEdMBsGA1UEAxMU
R2VvVHJ1c3QgU1NMIENBIC0gRzMwHhcNMTUwNDE3MDAwMDAwWhcNMTcwNDE2MjM1
OTU5WjB4MQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UE
BwwNU2FuIEZyYW5jaXNjbzEhMB8GA1UECgwYU2xhY2sgVGVjaG5vbG9naWVzLCBJ
bmMuMRkwFwYDVQQDDBAqLnNsYWNrLW1zZ3MuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAuRTjOTwZwkyZVzgtRZq1Y4Kn/hD7Lqr2ngWcJyFzmdXH
CxPKufvFsLA/V8MmaQH4gRC4BqZULeUI9foGkEr6yvANbfeC/H1GHAg20zz6kg8K
eNWbyPnGMgOxVDZ6UGRMTanSAa/cGt+C53c01Ds+nqAv7BLNaN7IqT/mNH+W0SE+
u/9Jsrl6dwih/RAzzNGZfTTVQ7GMvJxR9BJV0H5YyjKcvs2qsmwTuZK+Mca6qf8j
tR0w353c2ZLdBPEVasYeiMeJbc+PASF4ybvvzRzyAO3CVMXlxe+OuPrI49A8Eyjd
VVlRQP2g737X2vxytDtZfM4YN/2LH5XYRoThwgP1QQIDAQABo4IBsjCCAa4wKwYD
VR0RBCQwIoIQKi5zbGFjay1tc2dzLmNvbYIOc2xhY2stbXNncy5jb20wCQYDVR0T
BAIwADAOBgNVHQ8BAf8EBAMCBaAwKwYDVR0fBCQwIjAgoB6gHIYaaHR0cDovL2du
LnN5bWNiLmNvbS9nbi5jcmwwgZ0GA1UdIASBlTCBkjCBjwYGZ4EMAQICMIGEMD8G
CCsGAQUFBwIBFjNodHRwczovL3d3dy5nZW90cnVzdC5jb20vcmVzb3VyY2VzL3Jl
cG9zaXRvcnkvbGVnYWwwQQYIKwYBBQUHAgIwNQwzaHR0cHM6Ly93d3cuZ2VvdHJ1
c3QuY29tL3Jlc291cmNlcy9yZXBvc2l0b3J5L2xlZ2FsMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBTSb/eW9IU/cjwwfSPahXibo3xa
fDBXBggrBgEFBQcBAQRLMEkwHwYIKwYBBQUHMAGGE2h0dHA6Ly9nbi5zeW1jZC5j
b20wJgYIKwYBBQUHMAKGGmh0dHA6Ly9nbi5zeW1jYi5jb20vZ24uY3J0MA0GCSqG
SIb3DQEBCwUAA4IBAQB54B+WwpATiJSXE6Wa2dh3yVtUH21OWRPdBG8ty5t80nGO
tZ+lDWDinrmuUmm/yhdiSB9rJFI49bvtphYqTu0FBRxK2HuwfL+oFigoFBFPGcKh
nX5aUcbzicekyOLIgRgZENTBSCESpcdw8sm4Q+rJzV2XvdmZpMrtC3/m4jzQbXOh
5NE+lqdMS7R/9H1BubWe6RNXiLzzAeBMM3Oa/S8M1JjOkezvjLHvH5FhRHwiipNA
UPuLBoxYKTj6MP23sG32c8AfUbGrKWKnxyGekB7YRnltgYcmUIuCeQO5Y7UjpsZH
6x7XnCqm3UI6h7Ux6fcXxmOVtPK7GJd5SHWndrh3
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=San Francisco/O=Slack Technologies, Inc./CN=*.slack-msgs.com
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2928 bytes and written 500 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA384
    Session-ID: 55D4B1A494212D2B14C4AF0175919E0618655EA4D29BEFC5616F88AECCAB9A5E
    Session-ID-ctx:
    Master-Key: 9518153EFB53D7319BEECF85F6A86DD02012892DAEA8B003934675AC568CDA10B6EB1D98BB65DDA568D72F87B137989A
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1440002468
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
GET / HTTP/1.1
Host: ms136.slack-msgs.com
User-Agent: curl/7.44.0
Accept: */*
 
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 128

<html><body>Someone at Slack probably asked you to load this page to test your connection, and... it worked! Phew.</body></html>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Daniel Kahn Gillmor | 15 Aug 10:33 2015
Picon

[PATCH] Document weaknesses in SSLv2 and SSLv3

Acknowledge that SSLv3 is also widely considered to be insecure.

Also, provide references for people who want to know more about why
it's insecure.
---
 docs/curl.1 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/curl.1 b/docs/curl.1
index cf37d63..dd17f55 100644
--- a/docs/curl.1
+++ b/docs/curl.1
 <at>  <at>  -171,10 +171,11  <at>  <at>  a level of control).
 .IP "-2, --sslv2"
 (SSL) Forces curl to use SSL version 2 when negotiating with a remote SSL
 server. Sometimes curl is built without SSLv2 support. SSLv2 is widely
-considered insecure.
+considered insecure (see RFC 6176).
 .IP "-3, --sslv3"
 (SSL) Forces curl to use SSL version 3 when negotiating with a remote SSL
-server. Sometimes curl is built without SSLv3 support.
+server. Sometimes curl is built without SSLv3 support. SSLv3 is widely
+considered insecure (see RFC 7568).
 .IP "-4, --ipv4"
 This option tells curl to resolve names to IPv4 addresses only, and not for
 example try IPv6.
--

-- 
2.5.0

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Laurent Schumacher | 5 Aug 09:32 2015
Picon

Questions on cURL timing details

Dear All,

As a newbie to cURL, despite reading the documentation, I am confused 
about the timing details provided by cURL in a regular HTTP scenario. 
Here are my questions.

1. time_starttransfer

http://curl.haxx.se/docs/manpage.html defines it as "The time, in 
seconds, it took from the start until the first byte was just about to 
be transferred." As I understand it, that means the end of the 
processing of the request at the web server, and the departure of the 
first byte of the reply from the server.

However, on 
http://stackoverflow.com/questions/17638026/calculating-server-processing-time-with-curl, 
one can derive that that time_starttransfer is "the time (...) until the 
first byte arrived", at the client I guess.

Thus there would be half a round trip time (RTT) difference between the 
two, since one is defined at the web server, and the other at the client.

Since cURL is running at the client, I would not expect it to get to 
know when the web server is ready to send the first byte, so the arrival 
of the first byte at the client would be the reference. Can anyone confirm?

2. time_connect

http://curl.haxx.se/docs/manpage.html defines it as "The time, in 
seconds, it took from the start until the TCP connect to the remote host 
(or proxy) was completed." As I understand it, it means the moment the 
TCP SYN+ACK is received at the client originating the TCP connection to 
the web server. This is not the end of the three-way-handshake, since 
this would require a measurement at the web server when the third, final 
TCP ACK arrives from the client. Can anyone confirm?

3. Timing relations

In the most general case, without redirection nor proxy, is it right to 
expect that

time_namelookup <= time_connect <= time_pretransfer <= 
time_starttransfer <= time_total

Thanks in advance for any insight.
Sorry to bother you if these questions have already been answered 
elsewhere. Please point me to the reference document I was not smart 
enough to find.

Best regards,
LS
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Tech Bolek via curl-users | 17 Jul 02:51 2015
Picon

SHA2 support

Hello, as of which version does curl support SHA2? Our client is runing curl-7.16.4 and we would like to know if this one has SHA2 support. Thanks.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Hector Chan | 13 Jul 20:54 2015
Picon

curl and dual stack mode IPv4 and IPv6

Hi,

How does curl work with a domain with dual stack IPv4 and IPv6?  Without messing with the -4 and -6 options, which address would curl pick ?  Does curl pick the first address or IPv6 over IPv4, etc ?

Thanks,
Hector
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Gmane