Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSL connection reboots #134

Closed
dvv opened this issue Jan 26, 2015 · 19 comments
Closed

SSL connection reboots #134

dvv opened this issue Jan 26, 2015 · 19 comments

Comments

@dvv
Copy link
Contributor

@dvv dvv commented Jan 26, 2015

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
Copy link
Contributor

@sej7278 sej7278 commented Jan 26, 2015

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

@dvv
Copy link
Contributor Author

@dvv dvv commented Jan 26, 2015

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
Copy link
Contributor Author

@dvv dvv commented Jan 27, 2015

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
Copy link
Contributor Author

@dvv dvv commented Jan 27, 2015

A hackish fix here dvv@f4b2827

@sej7278
Copy link
Contributor

@sej7278 sej7278 commented Jan 27, 2015

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
Copy link
Contributor Author

@dvv dvv commented Jan 27, 2015

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
Copy link
Contributor

@sej7278 sej7278 commented Jan 27, 2015

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
Copy link
Collaborator

@nodemcu nodemcu commented Jan 27, 2015

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
Copy link
Contributor Author

@dvv dvv commented Jan 27, 2015

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

@sej7278
Copy link
Contributor

@sej7278 sej7278 commented Jan 27, 2015

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
Copy link

@oskar-r oskar-r commented Jan 30, 2015

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
Copy link
Contributor Author

@dvv dvv commented Jan 31, 2015

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

@Suxsem
Copy link

@Suxsem Suxsem commented Jan 31, 2015

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
Copy link

@Suxsem Suxsem commented Jan 31, 2015

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
Copy link

@Suxsem Suxsem commented Jan 31, 2015

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
Copy link

@oskar-r oskar-r commented Jan 31, 2015

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
Copy link
Contributor

@sej7278 sej7278 commented Feb 1, 2015

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
Copy link
Contributor Author

@dvv dvv commented Feb 1, 2015

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
Copy link

@eraclitux eraclitux commented Feb 1, 2015

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 nodemcu closed this as completed Mar 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants