RAM usage for mbedtls

[snahmad75]

I added more logs. Any idea why socket class fail to receive.

s_ssl_read_record_layer() returned -29312 (-0x7280)
D (18046) Socket: rc=0, MBEDTLS_ERR_SSL_WANT_READ=-26880
D (18052) Socket: << accept: sockFd: 4100
D (18058) HttpServerTask: HttpServer that was listening on port 443 has receiv
ed a new client connection; sockFd=4100
Stack free: 6688
Internal Heap free: 76208
Heap free: 10616:76208
D (18073) HttpParser: >> parse: socket: fd: 4100
D (18077) Socket: Socket::readToDelim=

[kolban]

According to the mbedtls docs, error code -0x7280 means that the connection indicated an End Of File condition:

https://tls.mbed.org/api/ssl_8h.html#ab ... 8ef9eb97f9

As to the cause, no idea. If it were me, I'd start looking at the client traces to see if we can see any rejection messages that might guide us. Worst case, we'd have to drop down to WireShark and examine the SSL protcol handshakes to see if we can spot why the connection is being closed.

[snahmad75]

I tried both client. My c++ application running on PC and chrome web browser.
Let me check if i get same error using these two client. i will check wire-shark logs tomorrow.

This is Https session can i see encrypted messages.

[snahmad75]

To let you know this example works with my openssl client and web browser.
https://github.com/espressif/esp-idf/tr ... ssl_server

[snahmad75]

Now my client keep connection alive when do post. Still crash. no more connection close error.

Now I am not getting s_ssl_read_record_layer() returned -29312 (-0x7280)

C:/Work/LibDev/esp32/esp-idf/components/mbedtls/library/ssl_tls.c:7042: <= rea
d
D (647522) Socket: rc=1, MBEDTLS_ERR_SSL_WANT_READ=-26880
D (647528) Socket: << accept: sockFd: 4100
D (647534) HttpServerTask: HttpServer that was listening on port 443 has recei
ved a new client connection; sockFd=4100
D (647542) HttpParser: >> parse: socket: fd: 4100
Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited)
. Exception was unhandled.

[snahmad75]

It look like something to do with Http Parsing. No stack oveflow and plenty of heap. I have not setup eclipse debugger yet. I can try debugging via gnu command line. I am using attached certificate and key string from header file. Can some one try to uses these and test HttpServer with post and enable SSL.

D (29334) Socket: rc=1, MBEDTLS_ERR_SSL_WANT_READ=-26880
D (29340) Socket: << accept: sockFd: 4100
D (29346) HttpServerTask: HttpServer that was listening on port 443 has receiv
ed a new client connection; sockFd=4100
D (29354) HttpParser: >> parse: socket: fd: 4100
Stack free: 10368
Internal Heap free: 74012
Heap free: 8420:74012
Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited)
. Exception was unhandled.

[snahmad75]

Can someone help me with HttpParser cause crash. I have attached the certificate i am using. can some reproduce at his side using HttpServer class with SSL enable.
httpPostHandler is post handler. Is there alternative Http server routine c or c++ which supports https post method.

void httpPostHandler(HttpRequest* pRequest, HttpResponse* pResponse)
{

std::string http_request = pRequest->getBody();
pResponse->close();
}

class HttpTask: public Task {
void run(void *data) {
ESP_LOGD("http", "Testing http ...");

SSLUtils::setKey(key);
SSLUtils::setCertificate(cert);

HttpServer* pHttpServer = new HttpServer();
pHttpServer->addPathHandler(
HttpRequest::HTTP_METHOD_POST,
"/",
httpPostHandler);

pHttpServer->start(43, true);

return;
}
};

[snahmad75]

D (72689) Socket: << receive: rc: 1
D (72693) Socket: << accept: sockFd: 8196
D (72699) HttpServerTask: HttpServer that was listening on port 443 has receiv
ed a new client connection; sockFd=8196
D (72707) HttpParser: >> parse: socket: fd: 8196
D (72721) Socket: >> receive: sockFd: 8196, length: 1, exact: 0
D (72727) Socket: before mbedtls_ssl_read
Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited)
. Exception was unhandled.

mbedtls_ssl_read cause crash.

Code: Select all

size_t Socket::receive(uint8_t* data, size_t length, bool exact) {
	ESP_LOGD(LOG_TAG, ">> receive: sockFd: %d, length: %d, exact: %d", m_sock, length, exact);
	if (exact == false) {
		int rc;
		if (getSSL()) {
			do {
				ESP_LOGD(LOG_TAG, "before mbedtls_ssl_read");
				rc = mbedtls_ssl_read(&m_sslContext, data, length);
				ESP_LOGD(LOG_TAG, "rc=%d, MBEDTLS_ERR_SSL_WANT_READ=%d", rc, MBEDTLS_ERR_SSL_WANT_READ);
			} while(rc == MBEDTLS_ERR_SSL_WANT_WRITE || rc == MBEDTLS_ERR_SSL_WANT_READ);
		} else {
			rc = ::lwip_recv_r(m_sock, data, length, 0);
			if (rc == -1) {
				ESP_LOGE(LOG_TAG, "receive: %s", strerror(errno));
			}
		}
		GeneralUtils::hexDump(data, rc);
		ESP_LOGD(LOG_TAG, "<< receive: rc: %d", rc);
		return rc;
	} // Read what we can, doesn't need to be an exact amount.

	size_t amountToRead = length;
	int rc;
	while(amountToRead > 0) {
		if (getSSL()) {
			do {
				rc = mbedtls_ssl_read(&m_sslContext, data, amountToRead);
			} while(rc == MBEDTLS_ERR_SSL_WANT_WRITE || rc == MBEDTLS_ERR_SSL_WANT_READ);
		} else {
			rc = ::lwip_recv_r(m_sock, data, amountToRead, 0);
		}
		if (rc == -1) {
			ESP_LOGE(LOG_TAG, "receive: %s", strerror(errno));
			return 0;
		}
		if (rc == 0) {
			break;
		}
		amountToRead -= rc;
		data += rc;
	}
	GeneralUtils::hexDump(data, length);
	ESP_LOGD(LOG_TAG, "<< receive: %d", length);
	return length;
} // receive_cpp

[snahmad75]

Hi,

If I send wrong SSL certificate or using wrong ssl method. It cause mbed TLS to crash. Is this code does not handle invalid SSL handshake.

It seems to me not handling connection close as well and crash.

Any suggestions?


Thanks,
Naeem

[kolban]

This looks like more of a problem with the implementation of the HTTP Server than it does look like a problem with mbedtls. When an incoming browser request is received by an HTTP server and the request is over SSL, the HTTP server should negotiate a good SSL channel before continuing. The error messages might lead one to believe that the issue is more that the SSL channel was not negotiated correctly for the incoming browser request.

Looking back through the history of this thread ... was it not dedicated to RAM utilization of mbedtls as opposed to problem solving mbedtls usage in application logic and libraries? This may be a good candidate for a new thread or a Github issue to the library you are using.