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