SSL connection reboots

[dvv]

This reboots mcu even without entering connection handler

do
  local KEY = "....."
  local thingspeak = function(t, h)
    local s = ("POST /update?api_key=%s&field1=%s&field2=%s HTTP/1.0\r\nHost: api.thingspeak.com\r\n\r\n"):format(
        KEY,
        t,
        h
      )
    local c = net.createConnection(net.TCP, 1)
    c:on("connection", function(c)
      print("connected")
      c:send(s, c.close)
    end)
    c:connect(443, "api.thingspeak.com")
  end
  thingspeak()
end

while non-SSL connection works just fine. What can be the cause? TIA

[sej7278]

is https even supported, it doesn't have the ram/flash to handle the certificates surely?

[dvv]

Well it seems so as per wiki, and I believe it's even compiled in by default. Unless, I'd vote to disable it until fixed.

So far I have to proxy via local nginx which lowers the value of the node as independent sensor reporter.

[dvv]

Disabled SSL_ENABLE switch, got compile-time error

make[2]: выход из каталога «/home/vd/projects/esp8266/nodemcu-firmware/app/spiffs»
xtensa-lx106-elf-gcc  -L../lib -nostdlib -T../ld/eagle.app.v6.ld -Wl,--no-check-sections -u call_user_start -Wl,-static -Wl,--start-group -lc -lgcc -lhal -lphy -lpp -lnet80211 -lwpa -lmain -ljson -lsmartconfig user/.output/eagle/debug/lib/libuser.a driver/.output/eagle/debug/lib/libdriver.a lwip/.output/eagle/debug/lib/liblwip.a json/.output/eagle/debug/lib/libjson.a ssl/.output/eagle/debug/lib/libssl.a upgrade/.output/eagle/debug/lib/libupgrade.a platform/.output/eagle/debug/lib/libplatform.a libc/.output/eagle/debug/lib/liblibc.a lua/.output/eagle/debug/lib/liblua.a mqtt/.output/eagle/debug/lib/mqtt.a smart/.output/eagle/debug/lib/smart.a wofs/.output/eagle/debug/lib/wofs.a spiffs/.output/eagle/debug/lib/spiffs.a modules/.output/eagle/debug/lib/libmodules.a -Wl,--end-group -o .output/eagle/debug/image/eagle.app.v6.out 
ssl/.output/eagle/debug/lib/libssl.a(ssl_loader.o): In function `ssl_obj_load':
/home/vd/projects/esp8266/nodemcu-firmware/app/ssl/ssl/ssl_loader.c:90: undefined reference to `default_private_key'
/home/vd/projects/esp8266/nodemcu-firmware/app/ssl/ssl/ssl_loader.c:90: undefined reference to `default_private_key_len'
/home/vd/projects/esp8266/nodemcu-firmware/app/ssl/ssl/ssl_loader.c:90: undefined reference to `default_certificate'
/home/vd/projects/esp8266/nodemcu-firmware/app/ssl/ssl/ssl_loader.c:90: undefined reference to `default_certificate_len'
collect2: error: ld returned 1 exit status

Please, consider fixing

[dvv]

A hackish fix here https://github.com/dvv/nodemcu-firmware/commit/f4b2827938091667acf5edf74f51f87093c8059d

[sej7278]

ssl support is just for the cloud update process, not for https clients i believe. i don't see the point of disabling it

[dvv]

Memory. 25kB free with the above patch vs circa 18kB without. Where to read about cloud update of nodemcu? Does cloud updating differ from issuing client request to cloud?

[sej7278]

as with all esp8266 info, there's nothing documented about cloud upgrade. its part of the sdk, not nodemcu-specific. i see your point about saving memory.

mqtt isn't the only module that uses ssl though:

nodemcu-firmware$ grep -irl ssl * 2>/dev/null 
app/Makefile
app/include/lwip/app/espconn.h
app/include/ssl/app/espconn_ssl.h
app/include/ssl/ssl_bigint.h
app/include/ssl/ssl_config.h
app/include/ssl/ssl_crypto.h
app/include/ssl/ssl_crypto_misc.h
app/include/ssl/ssl_os_port.h
app/include/ssl/ssl_ssl.h
app/include/ssl/ssl_tls1.h
app/include/user_config.h
app/lwip/app/espconn.c
app/modules/net.c
app/ssl/Makefile
app/ssl/app/Makefile
app/ssl/app/espconn_secure.c
app/ssl/app/espconn_ssl.c
app/ssl/crypto/Makefile
app/ssl/crypto/ssl_aes.c
app/ssl/crypto/ssl_bigint.c
app/ssl/crypto/ssl_crypto_misc.c
app/ssl/crypto/ssl_hmac.c
app/ssl/crypto/ssl_md2.c
app/ssl/crypto/ssl_md5.c
app/ssl/crypto/ssl_rc4.c
app/ssl/crypto/ssl_rsa.c
app/ssl/crypto/ssl_sha1.c
app/ssl/ssl/Makefile
app/ssl/ssl/ssl_asn1.c
app/ssl/ssl/ssl_gen_cert.c
app/ssl/ssl/ssl_loader.c
app/ssl/ssl/ssl_openssl.c
app/ssl/ssl/ssl_os_port.c
app/ssl/ssl/ssl_p12.c
app/ssl/ssl/ssl_tls1.c
app/ssl/ssl/ssl_tls1_clnt.c
app/ssl/ssl/ssl_tls1_svr.c
app/ssl/ssl/ssl_x509.c
app/upgrade/upgrade.c
include/upgrade.h
lib/libssl.a

they seem to be using #ifdef UPGRADE_SSL_ENABLE

[nodemcu]

latest build, replace the open-source ssl lib with lib/libssl.a(no source available since sdk 0.9.5). no reboots. have a try.

[dvv]

Hmmm. Closed source SSL. A bit paranoid, but how do we know it does what we mean it to do?

[sej7278]

yup, 0.9.5 has gone back to closed-source ip stack (lwip) and ssl for some reason. not really a nodemcu issue, but an sdk one, and a bit worrying.

[oskar-r]

There still appears to be some issues with SSL. Have tried to connect to gmail smtp with several versions of the firmware. Pre SDK 0.9.5 caused reboot Build 20150126 worked logged in an send mail Build 20150127 results in a failed connect.

NodeMCU 0.9.5 build 20150126  powered by Lua 5.1.4
lua: cannot open init.lua
> print(node.heap())
24080
> dofile("gmail2.lua")
> Connected.
Logged in.
Mail sent
disconnect

NodeMCU 0.9.5 build 20150127  powered by Lua 5.1.4
lua: cannot open init.lua
> print(node.heap())
22496
> dofile("gmail2.lua")
> disconnect

Sample code can be found in this post. http://www.esp8266.com/viewtopic.php?p=8208&sid=9f22fda870576d5612657b21966116c0#p8208

[dvv]

I confirm that I also still can't connect to a https:// server.

[Suxsem]

I don't know if it's related, but I'm having problems with SSL connection...

i configured my MQTT broker to accept any connections and i can connect to it with something like mosquitto_sub.exe -h 192.168.1.50 -p 8883 --cafile ca.crt --insecure -t test but if i try to connect to the broker from nodemcu (with secure enabled) m:connect("192.168.1.50", 8883, 1) the esp8266 reboots without errors

all fine without secure connection.

1) Do I have to put ca.crt somewhere on the esp8266? 2) I'm using 1024bit key...it's too much for the esp8266?

[Suxsem]

I just tried the fragment example: sk=net.createConnection(net.TCP, 1) sk:on("receive", function(sck, c) print(c) end ) sk:on("connection", function(sck) sck:send("GET / HTTPS/1.1\r\nHost: www.google.com.hk\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n") end ) sk:connect(443,"173.194.72.199") the board reboots. so i think that we have some problem with SSL... i'm on 20150127 build

[Suxsem]

On 20150126 (not 27) the board doesn't reboot. I still can't connect to MQTT broker with SSL/TLS on, i get this error on the broker: 1422728671: Client connection from 192.168.1.103 failed: error:1408A10B:lib(20):func(138):reason(267). maybe the TLS version on the esp8266 is too old?

[oskar-r]

20150126 is probably memory related Tried some different random https request with openssl s_client just to investigate the size of the handshake. Googles 10.5 kB ->disconnect (Protocol : TLSv1.2 Chiper ECDHE-RSA-AES128-GCM-SHA256) telia.com 6 kB -> disconnect (Protocol : TLSv1.2 Cipher AES128-GCM-SHA256) openssl.org about 4 kB -> connect but reboot after send (Protocol: TLSv1.2Chiper DHE-RSA-AES256-GCM-SHA384)

turns out that openssl.org's response was quite large and it works if you specifiy the GET e.g "GET /images/page-corner-tr.gif".

Same test in 20150127 results in disconnect. So i guest that the question is what ssl related changes where there between build 20150126 and build 20150127.

Second, is there a way to handle "large" responses on https requests without running out of heap.

[sej7278]

this is why i always doubted this chip can do ssl, the certificates are just too large. same with arduino's and spark cores.

[dvv]

Well, this chip does have memory to store responses -- filesystem. Wonder if the most expensive portion of SSL -- handshake -- can be worked around by using filesystem to save response for analysing it later in memory chunk by chunk?

[eraclitux]

yup, 0.9.5 has gone back to closed-source ip stack (lwip) and ssl for some reason. not really a nodemcu issue, but an sdk one, and a bit worrying.

I see lot of potential in this platform but using closed source blob to make IoT is not feasible. It's not just paranoid, a single vendor cannot guarantee same QA on code as open source community can, specially on cryptographic code.