On 10/15/2015 11:51 AM, Frederick Chin wrote:
> Raul,
> With EWB Web Server <-> Stunnel <-> Internet <-> Users,

This is exactly the config i've listed before :

accept = 443
connect = 80

and

EWB web server should be on IP 127.0.0.1 and port 80

Raul

Matthew,

<< Then the config is the wrong way around surely? Maybe I just don't understand, but if the web server is on 8899, then the SSL must be the other one. >>

That's just it - his configuration says the *opposite*.  The accept is for the SSL, and the connect is for the web server.  He needs to do what Raul suggests, make the web server listen on port 80 for only localhost connections, and then have everything external go through port 443 (the default SSL) port.  That way there's no chance of anyone accessing anything directly *without* https, everything is 100% secure, and there's no fiddling around with cross-origin requests because the app was loaded from one port/protocol, but server requests for datasets, etc. are using a different port/protocol.  That is the "best practices" way to use Stunnel with the EWB Web Server and any other services that you wish to secure, such as email.

Tim Young
Elevate Software
www.elevatesoft.com

Raul,

/*
This is exactly the config i've listed before :

accept = 443
connect = 80

and

EWB web server should be on IP 127.0.0.1 and port 80
*/

I have configured Stunnel and EWB as above. Based on my understanding so far, any user who attempts to connect to the EWB web server without using the https prefix for the URL will get blocked. If the URL with the https is received, Stunnel will pass the request to EWB via port 80.

Since EWB is only listening to port 80 from localhost, the request will be received and handled.

Can I assume that this setup is secure enough to prevent viewing of decrypted user names and passwords?

Frederick

Frederick Chin wrote:

> any user who attempts to connect to the EWB web server without using
> the https prefix for the URL will get blocked.

You should, of course, verify that. I think myself I'd move the EWB
server to a port other than 80 just to be completely sure it can't
accidentally open up. Seen that happen in the press as the source of a
data leak before...

--

Matthew Jones

"Matthew Jones" wrote:

/*
You should, of course, verify that. I think myself I'd move the EWB
server to a port other than 80 just to be completely sure it can't
accidentally open up. Seen that happen in the press as the source of a
data leak before...
*/

Sounds like a great plan changing port 80 to some other port number. I'll try this.

Frederick

On 10/16/2015 3:16 AM, Frederick Chin wrote:
> I have configured Stunnel and EWB as above. Based on my understanding so far, any user who attempts to connect to the EWB web server without using the https prefix for the URL will get blocked.

Not really blocked but since nothing is listening on port 80 on the
public IP there is no response at all (web server only listens on
127.0.0.1 IP).

You can test it yourself - try to connect to http://<your public ip>

> If the URL with the https is received, Stunnel will pass the request to EWB via port 80. Since EWB is only listening to port 80 from localhost, the request will be received and handled.

Yes.

Just to be clear URL has nothing to do with your server - that is just a
an indication for the client browser to connect to port 443 (without you
having to specify this) and use SSL/TLS. Again this all happens on
client PC and browser - your server simply sees http requests
connections coming in ion port 443.


> Can I assume that this setup is secure enough to prevent viewing of decrypted user names and passwords?

This will prevent anyone from listening in and viewing traffic client is
exchanging with the server (for example in shared wifi like public cofee
shop). Do make sure your certs are using SHA-2 (that is default anyways
if you get a cert from CA) and newer versions of stunnel disable SSLv2
and SSLv3 so you should be good to go.

Note that you still need to make sure your web server does not "leak"
usernames/passwords - for example do not server them up as dataset
queries since anybody can access those thru a URL and SSL will not help.

Similarly make sure usernames/passwords are not accessible from your
application (i.e. do not download list of them from server and validate
on client side - all authentication should be validated on server side).

Finally make sure you don't accept empty or or default
usernames/passwords and hopefully none of your users uses trivial ones
(like '12345' or such).

If you do all of that then you will be as secure as you can get with a
web app for now.

Raul

Raul,

Thanks for the detailed advice.

/*
Note that you still need to make sure your web server does not "leak"
usernames/passwords - for example do not server them up as dataset
queries since anybody can access those thru a URL and SSL will not help.

Similarly make sure usernames/passwords are not accessible from your
application (i.e. do not download list of them from server and validate
on client side - all authentication should be validated on server side).
*/

Now, this is interesting. Given that I am loading the data either by queries or loading rows, are you suggesting the use of server modules or the dataset adapters to perform the validation since it looks like it requires a function call by the application to the server?

Does the EWB manual provide examples on how to do this?

Frederick

Frederick,

<< Now, this is interesting. Given that I am loading the data either by queries or loading rows, are you suggesting the use of server modules or the dataset adapters to perform the validation since it looks like it requires a function call by the application to the server? >>

If you ask for authentication information from the user, you can cache that locally in the application and use it for dataset requests (https only), but don't allow the *web server side* of things to return *anything* about the users/passwords/hashes that are used to authenticate any dataset requests/logins/etc.

Caching authentication locally in memory in an EWB application is relatively harmless because if a bad actor already has access to the EWB client application in the active browser logged in with a specific user account, then all bets are already off and the user screwed up.

You *can* do things like clear out the cached authentication information if there isn't any activity after a certain amount of time, but physical security of the client application/OS is beyond the scope of what you, as a developer, can provide, other than to display the appropriate warnings about not using the application on public machines like those at cafes, the library, or similar places.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

/*
If you ask for authentication information from the user, you can cache that locally in the application and use it for dataset requests (https only), but don't allow the *web server side* of things to return *anything* about the users/passwords/hashes that are used to authenticate any dataset requests/logins/etc.

Caching authentication locally in memory in an EWB application is relatively harmless because if a bad actor already has access to the EWB client application in the active browser logged in with a specific user account, then all bets are already off and the user screwed up.

You *can* do things like clear out the cached authentication information if there isn't any activity after a certain amount of time, but physical security of the client application/OS is beyond the scope of what you, as a developer, can provide, other than to display the appropriate warnings about not using the application on public machines like those at cafes, the library, or similar places.
*/

Thanks. I will keep the above in mind when authenticating user names and passwords.

Frederick

Raul,

/*
Not really blocked but since nothing is listening on port 80 on the
public IP there is no response at all (web server only listens on
127.0.0.1 IP).

You can test it yourself - try to connect to http://<your public ip>
*/

I did the following tests:-

Stunnel Configuration:-

Accept=443
Connect=80

EWB Server:-

Port 80

Browser (Chrome):-

localhost/<app.html> => OK
https://localhost/<app.html> => OK

Stunnel Configuration:-

Accept=443
Connect=8081

EWB Server:-

Port 8081

Browser (Chrome):-

localhost/<app.html> => Connection Refused
https://localhost/<app.html> => OK

It looks like the second non-standard port setting is more secure.

When I attempt to use a smartphone to connect as follows:-

https://<dynamic dns>/<app.html>

I get a connection failed. A local ping of the dynamic DNS results in a valid public IP address. I'll need to research this further.

In both https prefixes in the URL, Chrome complains the connection is not private and the https in the URL is crossed out in red. Should I worry about this?

Frederick