search

Othernet-Project / librarian

Content indexer for Outernet receivers
GNU General Public License v3.0
47 stars 14 forks source link

Enable SSL Options #405

Open JDogHerman opened 7 years ago

JDogHerman commented 7 years ago

Feature Request;

Could there be a way for the site to support SSL? Maybe on first boot the device generates a self signed SSL cert. The issue I see is that the client will alarm on a self signed ssl. BUT it would allow an established session to remain secure after the cert was accepted by the client.

Another option would be to allow admins of the device to supply a valid certificate signed by a CA after supplying a custom hostname for the outernet.

abgoyal commented 7 years ago

for the first part - the warning displayed by browsers is quite scary, and i think even that exception granting process is being retired by the major browsers soon. so there is a lot of harm in adding a self signed cert.

For the second - that could technically work. though it will be very challenging for vast majority of users to use any such option. I will put it on The List(tm), let see. :D

Can you explain the use case where this is important? While I would have added https at the very beginning if there was a reasonable way to do it, I believe the requisite security in our current context comes from the Wifi access security, not thru https.

JDogHerman commented 7 years ago

Since the superuser creds are passed in the clear and these creds are able to log into the os, it brings concern that a session could have the creds sniffed. In addition many users reuse creds between multiple services creating a incentive for the attacker.

I haven't seen wifi access security yet. Is there an ability to create a 2nd SSID for management that has WPA2?

abgoyal commented 7 years ago

you can enable WPA2 security on the main SSID. Its just disabled by default.

Note that in this context, the "attacker" would have to be someone local, with access to the wifi and wifi creds. Its not the same situation as a regular internet service where the attacker can be anyone, anywhere in the world.

One option would be just use an ssh tunnel for admin purposes.

In any case, there is no reasonable, user friendly way to achieve https in this setup. Its unfortunate, true. I would have liked to have it.