Closed dvv closed 9 years ago
is https even supported, it doesn't have the ram/flash to handle the certificates surely?
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.
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
ssl support is just for the cloud update process, not for https clients i believe. i don't see the point of disabling it
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?
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
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.
Hmmm. Closed source SSL. A bit paranoid, but how do we know it does what we mean it to do?
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.
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
I confirm that I also still can't connect to a https:// server.
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?
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
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?
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.
this is why i always doubted this chip can do ssl, the certificates are just too large. same with arduino's and spark cores.
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?
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.
This reboots mcu even without entering connection handler
while non-SSL connection works just fine. What can be the cause? TIA