SSL connection reboots #134

dvv · 2015-01-26T06:24:02Z

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 · 2015-01-26T19:58:49Z

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

dvv · 2015-01-26T20:13:56Z

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 · 2015-01-27T06:50:46Z

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 · 2015-01-27T07:37:29Z

A hackish fix here dvv@f4b2827

sej7278 · 2015-01-27T09:20:46Z

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 · 2015-01-27T09:38:58Z

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 · 2015-01-27T11:07:04Z

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 · 2015-01-27T12:49:54Z

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 · 2015-01-27T16:16:10Z

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

sej7278 · 2015-01-27T16:30:43Z

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 · 2015-01-30T22:11:48Z

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 · 2015-01-31T06:42:02Z

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

Suxsem · 2015-01-31T13:06:48Z

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.

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

Suxsem · 2015-01-31T14:05:36Z

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 · 2015-01-31T18:39:23Z

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 · 2015-01-31T21:41:48Z

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 · 2015-02-01T00:10:25Z

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 · 2015-02-01T06:47:44Z

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 · 2015-02-01T14:59:59Z

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.

nodemcu closed this as completed Mar 18, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SSL connection reboots #134

SSL connection reboots #134

dvv commented Jan 26, 2015

sej7278 commented Jan 26, 2015

dvv commented Jan 26, 2015

dvv commented Jan 27, 2015

dvv commented Jan 27, 2015

sej7278 commented Jan 27, 2015

dvv commented Jan 27, 2015

sej7278 commented Jan 27, 2015

nodemcu commented Jan 27, 2015

dvv commented Jan 27, 2015

sej7278 commented Jan 27, 2015

oskar-r commented Jan 30, 2015

dvv commented Jan 31, 2015

Suxsem commented Jan 31, 2015

Suxsem commented Jan 31, 2015

Suxsem commented Jan 31, 2015

oskar-r commented Jan 31, 2015

sej7278 commented Feb 1, 2015

dvv commented Feb 1, 2015

eraclitux commented Feb 1, 2015

Navigation Menu

SSL connection reboots #134

SSL connection reboots #134

Comments

dvv commented Jan 26, 2015

sej7278 commented Jan 26, 2015

dvv commented Jan 26, 2015

dvv commented Jan 27, 2015

dvv commented Jan 27, 2015

sej7278 commented Jan 27, 2015

dvv commented Jan 27, 2015

sej7278 commented Jan 27, 2015

nodemcu commented Jan 27, 2015

dvv commented Jan 27, 2015

sej7278 commented Jan 27, 2015

oskar-r commented Jan 30, 2015

dvv commented Jan 31, 2015

Suxsem commented Jan 31, 2015

Suxsem commented Jan 31, 2015

Suxsem commented Jan 31, 2015

oskar-r commented Jan 31, 2015

sej7278 commented Feb 1, 2015

dvv commented Feb 1, 2015

eraclitux commented Feb 1, 2015