[GH-ISSUE #258] SSID & password sent unsecured #215

New issue

Closed

opened 2026-02-28 01:24:08 +03:00 by kerem · 4 comments

kerem commented

2026-02-28 01:24:08 +03:00

Owner

Originally created by @pratikpanchal22 on GitHub (Dec 4, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/258

Configuring the network from the captive portal sends the SSID and APPSK as a GET request to the server running on ESP unsecured. The SSID and APPSK are seen in the url:

http://192.168.4.1/wifisave?s=HomeWifi&p=homeWifi402754

This is a security flaw and allows the snoopers to hijack the WiFi credentials very easily.

What would be a feasible solution for that?

Originally created by @pratikpanchal22 on GitHub (Dec 4, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/258 Configuring the network from the captive portal sends the SSID and APPSK as a GET request to the server running on ESP unsecured. The SSID and APPSK are seen in the url: `http://192.168.4.1/wifisave?s=HomeWifi&p=homeWifi402754 ` This is a security flaw and allows the snoopers to hijack the WiFi credentials very easily. What would be a feasible solution for that?

kerem closed this issue

2026-02-28 01:24:08 +03:00

kerem commented

2026-02-28 01:24:08 +03:00

Author

Owner

@WilliamFrasson commented on GitHub (Dec 6, 2016):

I hope that an https server should ne used instead of the official http server,
I ask to all member...Is it possible?

@WilliamFrasson commented on GitHub (Dec 6, 2016): I hope that an https server should ne used instead of the official http server, I ask to all member...Is it possible?

kerem commented

2026-02-28 01:24:08 +03:00

Author

Owner

@cosmocracy commented on GitHub (Dec 20, 2016):

In this case the HTTPS server would have to be run on the ESP8266. The ESP8266 barely supports HTTPS as a client--even then using older TLSv1.1--so I doubt you'll see this capability in the future on the ESP8266 platform. Better to open an issue at the ESP8266 project instead of here.

For reference, see this issue (among the others in the ESP8266 project): https://github.com/esp8266/Arduino/issues/2733

I think this issue is a "non-issue" for WiFiManager for the following reasons:

The vulnerability only exists for the small duration of time that the ESP8266 is in AP mode
You're unlikely to have anyone else connected to the ESP8266 AP during your config session
What you're asking for wouldn't work the way you want since you wouldn't have an SSL certificate on the ESP8266--your browser would give you a DANGER--CANNOT VERIFY SITE style error when you try to configure (assuming you managed to get the crypto and a self-signed cert served out by the ESP8266)

@cosmocracy commented on GitHub (Dec 20, 2016): In this case the HTTPS server would have to be run on the ESP8266. The ESP8266 barely supports HTTPS as a client--even then using older TLSv1.1--so I doubt you'll see this capability in the future on the ESP8266 platform. Better to open an issue at the [ESP8266 project](https://github.com/esp8266/Arduino) instead of here. For reference, see this issue (among the others in the ESP8266 project): https://github.com/esp8266/Arduino/issues/2733 I think this issue is a "non-issue" for WiFiManager for the following reasons: * The vulnerability only exists for the small duration of time that the ESP8266 is in AP mode * You're unlikely to have anyone else connected to the ESP8266 AP during your config session * What you're asking for wouldn't work the way you want since you wouldn't have an SSL certificate on the ESP8266--your browser would give you a DANGER--CANNOT VERIFY SITE style error when you try to configure (assuming you managed to get the crypto and a self-signed cert served out by the ESP8266)

kerem commented

2026-02-28 01:24:08 +03:00

Author

Owner

@tablatronix commented on GitHub (Dec 29, 2016):

It should at least be a post so it is not stored in access logs. Someone made a pull request to do this already ideallly allow both.

@tablatronix commented on GitHub (Dec 29, 2016): It should at least be a post so it is not stored in access logs. Someone made a pull request to do this already ideallly allow both.

kerem commented

2026-02-28 01:24:08 +03:00

Author

Owner

@suculent commented on GitHub (Apr 3, 2017):

Yes, this should be a POST from OWASP point of view, regardless transport security.

@suculent commented on GitHub (Apr 3, 2017): Yes, this should be a POST from OWASP point of view, regardless transport security.