raysatiro
(Ray Satiro)
August 24, 2018, 5:25pm
1
mbedtls_ssl_read returns 0 if the read end of the underlying transport was closed,
but isn’t specific if it was closed unclean without the close notify. Can you clarify what the difference is between returning 0 and MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY? Does returning 0 give any indication whether or not a close notify was received? This is currently being discussed at the curl project.
opened 02:42PM - 20 Aug 18 UTC
closed 11:50AM - 13 Apr 19 UTC
TLS
<!-- Only file bugs here! Ask questions on the mailing list https://curl.haxx.se… /mail/
Do not file security vulnerabilities here, e-mail curl-security at haxx.se
There are collections of known issues to be aware of:
https://curl.haxx.se/docs/knownbugs.html
https://curl.haxx.se/docs/todo.html -->
### I did this
Connected to many axis security cameras in https mode and some return curl error (56) : recv error immediatly after getting a complete response. Similar version of curl using openssl back end do not produce the error.
### I expected the following
No error code to stop application.
### curl/libcurl version
7.48, 7.61
### mbedtls 2.2.1 and 2.12.0
~~~
[curl -V output]
C:\Program Files\exacqVision\Server>curl -v -uroot:pass --insecure --digest https://172.19.234.58/axis-cgi/disks/list.cgi?diskid=all
* Trying 172.19.234.58...
* Connected to 172.19.234.58 (172.19.234.58) port 443 (#0)
* mbedTLS: Connecting to 172.19.234.58:443
* mbedTLS: Set min SSL version to TLS 1.0
* mbedTLS: Handshake complete, cipher is TLS-RSA-WITH-AES-256-CBC-SHA
* Dumping cert info:
* cert. version : 3
* serial number : 5B:76:C7:25
* issuer name : C=us, ST=in, L=fishers, O=exacq, OU=ipcam, CN=172.19.234.58
* subject name : C=us, ST=in, L=fishers, O=exacq, OU=ipcam, CN=172.19.234.58
* issued on : 2018-08-17 13:01:24
* expires on : 2019-08-17 04:00:00
* signed using : RSA with SHA-256
* RSA key size : 2048 bits
* SSL connected
* Server auth using Digest with user 'root'
> GET /axis-cgi/disks/list.cgi?diskid=all HTTP/1.1
> Host: 172.19.234.58
> User-Agent: curl/7.48.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Date: Mon, 20 Aug 2018 14:41:10 GMT
< Server: Apache/2.4.25 (Unix) OpenSSL/1.0.2k
< WWW-Authenticate: Digest realm="AXIS_ACCC8E6882E1", nonce="CSx95t5zBQA=feda953692070ff1fd8247548ded99a94878c6d7", algorithm=MD5, qop="auth"
< Content-Length: 381
< Content-Type: text/html; charset=iso-8859-1
<
* Ignoring the response-body
* Connection #0 to host 172.19.234.58 left intact
* Issue another request to this URL: 'https://172.19.234.58/axis-cgi/disks/list.cgi?diskid=all'
* Found bundle for host 172.19.234.58: 0x44bb30 [can pipeline]
* Re-using existing connection! (#0) with host 172.19.234.58
* Connected to 172.19.234.58 (172.19.234.58) port 443 (#0)
* WARNING: Using weak random seed
* Server auth using Digest with user 'root'
> GET /axis-cgi/disks/list.cgi?diskid=all HTTP/1.1
> Host: 172.19.234.58
> Authorization: Digest username="root", realm="AXIS_ACCC8E6882E1", nonce="CSx95t5zBQA=feda953692070ff1fd8247548ded99a94878c6d7", uri="/axis-cgi/disks/list.cgi?diskid=all", cnonce="YzFhYzUwNjFmMzVmNGQxZGRmZmUxOTU3MmZiOWE5NGY=", nc=00000001, qop=auth,
response="52ec705ae91950d4f660cd4e140b6c43", algorithm="MD5"
> User-Agent: curl/7.48.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: text/xml
<
<?xml version="1.0"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.axis.com/vapix/http_cgi/disk/list1.xsd">
<disks numberofdisks="2" > <disk diskid="SD_DISK" name="" totalsize="31154688" freesize="31058560" cleanuplevel="0" cleanupmaxage="7" cleanuppolicy="fifo" locked="no" full="no" readonly="no" status="OK" filesystem="vfat" group="S0" requiredfilesyste
m="none" encryptionenabled="false" diskencrypted="false"/>
<disk diskid="NetworkShare" name="" totalsize="0" freesize="0" cleanuplevel="90" cleanupmaxage="7" cleanuppolicy="fifo" locked="no" full="no" readonly="no" status="disconnected" filesystem="cifs" group="S1" requiredfilesystem="none" encryptionenabl
ed="false" diskencrypted="false"/>
</disks> </root>
* Closing connection 0
curl: (56) Failure when receiving data from the peer
~~~
### operating system
Windows 7 (64), Windows 10
curl:master
← curl:bagder/mbedtls-ssl_read-zero
opened 09:59PM - 20 Aug 18 UTC
Patch-by: @jshanab
Fixes #2899
roneld01
(Ron Eldor)
August 27, 2018, 9:39am
2
Hi Ray,
As you can see from our example , when mbedtls_ssl_read()
returns 0, it’s mostly because the connection was reset by peer, and you should try to reconnect.
0 is returned when the read cb function returns EOF
. It is not necessarily because the remote peer gracefully shut down the connection, and is not returned when the Close Notify warning has been received.
Regards,
Mbed TLS Team member,
Ron