Jump to content

Do I really need to use SSL?


wgstarks

Recommended Posts

I've been using a self-signed certificate on my unraid server but this causes a problem when trying to launch a terminal session in Safari (bug in Safari). I've been trying to remember that I have to use Firefox instead, but usually I forget. Been using Safari since it's original release and changing is hard ?.

 

I saw a post recently that if I don't use SSL then terminal sessions will work in Safari. The server is not exposed to WAN. If I need remote access I use openvpn on a bare metal pfSense firewall appliance. What sort of security issues would I be risking with running the server on my local network without SSL?

Link to comment

Do you have any family members who might want to steal your data?

 

Seriously though, no. You don't need https to connect to your web GUI in your own home. However, unless I'm mistaken, it isn't https that's the issue with Safari. I believe - and I'm sure I'll be corrected if I'm wrong - that the Safari problem is caused by you setting a password for the root account. If you stay with the default null password then Safari's fine. The question is, do you want to run without a root password?

 

I simply removed Safari from the Dock and put Firefox in its place and set it as the default browser. Now it's much more difficult for me to launch Safari because it isn't "there" any more.

Link to comment
44 minutes ago, wgstarks said:

What sort of security issues would I be risking with running the server on my local network without SSL?

Fairly obscure risks at the moment. A compromised device on your local lan could watch the traffic on your network and see everything you transmit and receive from the webGUI.

 

It's not a risk that can be ignored, but as long as you know it exists, and there is a way to secure it, then I wouldn't worry about it.

 

Look at it this way. If you discover that you have had a compromised device on your lan, you are aware of what info may have leaked. Whether that knowledge scares you into securing all the things, or you are more of the "meh, it's probably not going to hurt me physically or financially, so why bother with the hassle" type is then in your court.

Link to comment
2 minutes ago, jonathanm said:

A compromised device on your local lan could watch the traffic on your network and see everything you transmit and receive from the webGUI.

 

A local third party can not see all traffic your server is sending. A switch relays frames between peers only and unless that third party is connected to a monitor (span) port of the switch, it may catch the occasional broadcast packets,  but nothing sensitive.

 

Using HTTP locally doesn't bring any risk.

 

Link to comment
1 minute ago, bonienl said:

A local third party can not see all traffic your server is sending. A switch relays frames between peers only

True, but a dumb ethernet hub (not switch) relays all traffic to all ports. In this day and age, switches are probably 99.999% of what's out there, but it's theoretically possible that somebody might still be trying to use a 10Mbit Hub. I sincerely doubt it, but the possibility is there.

Link to comment

I highly doubt anyone is still using a 10Mb half duplex ethernet hub these days. These aren't made any more for over a decade, but theoretically somebody could have opened a closet, dusted the box, and decided to use it (and not complaining about the very poor performance). :)

 

Link to comment
26 minutes ago, John_M said:

However, unless I'm mistaken, it isn't https that's the issue with Safari. I believe - and I'm sure I'll be corrected if I'm wrong - that the Safari problem is caused by you setting a password for the root account. If you stay with the default null password then Safari's fine. The question is, do you want to run without a root password?

Well, that sucks.?

Don't really want to eliminate the password. Don't really want to replace Safari with Firefox either. I like Safari much better. Maybe if I hold my breath apple will fix the bug.?

 

Thanks for the info though.

Link to comment
46 minutes ago, bonienl said:

I highly doubt anyone is still using a 10Mb half duplex ethernet hub these days.

Probably not for unraid, but I guarantee that some cheap business outfit using XP machines still has one in service, because it hasn't failed yet. I've seen some pretty crusty network closets.

Link to comment
1 hour ago, John_M said:

However, unless I'm mistaken, it isn't https that's the issue with Safari.

 

The issue is websockets. When Safari is used with HTTPS and a password for root is set, Safari will not allow websocket traffic to passthrough. This could be seen on the dashboard page which did not update the CPU load graphs.

 

The problem was "bypassed" by setting up a long interval polling mechanism instead when Safari is detected as browser. This allows one way traffic, so the CPU loading was solved, but e.g. a terminal window (which requires bidirectional traffic) still doesn't work.

 

I can't remember in which unRAID version this was done, but anyway I recommend to use the latest version at all times.

 

Link to comment
1 hour ago, bonienl said:

A local third party can not see all traffic your server is sending. A switch relays frames between peers only and unless that third party is connected to a monitor (span) port of the switch, it may catch the occasional broadcast packets,  but nothing sensitive.

 

Unless DNS is used and an attacker is using DNS poisoning to capture the connect.

Link to comment

IF you go back to using http:  rather than https:   you are going to find that a lot of MODERN Browsers are going to take exception to going to an unsecured site.  Then you will have to figure out how to convince the Browser that you really want to have access to this site.  (I know that I have problems with this on my Ubiquiti router.) 

Link to comment
17 minutes ago, Frank1940 said:

IF you go back to using http:  rather than https:   you are going to find that a lot of MODERN Browsers are going to take exception to going to an unsecured site.

 

That's true but Firefox, for example, simply displays a broken padlock icon which, while providing a warning, in no way interferes with your ability to access the site. Even browsers that bitch about it can to told that this one is an exception. I got tired of OCSP responder timed out errors (24 views but no comments!) and switched back to http with no problems.

Link to comment
32 minutes ago, Frank1940 said:

IF you go back to using http:  rather than https:   you are going to find that a lot of MODERN Browsers are going to take exception to going to an unsecured site.  Then you will have to figure out how to convince the Browser that you really want to have access to this site.  (I know that I have problems with this on my Ubiquiti router.) 

Yeah. Had to go through pretty much the same thing to use a self-signed cert.

Link to comment
11 minutes ago, wgstarks said:

Yeah. Had to go through pretty much the same thing to use a self-signed cert.

 

That's actually different. Browsers are (quite rightly) more suspicious of https transactions with self-signed certificates than they are of unencrypted http transactions. Either way you can tell them to make an exception.

 

But even when you have a valid certificate, if it can't be verified as being valid because the signing authority's responder doesn't respond you get an error! I thought that once the certificate had been verified the proof was "stapled", like the receipt you get from a store check-out to your purchase.

 

Link to comment

The whole point with certificates is they need to be signed by an acknowledged certificate authority (CA) to guarantee their valid identity.

 

Anybody can make a self-signed certificate, but this doesn't validate its identity (you can impersonate anybody), hence browsers reject such certificates by design. Accepting an exception means you trust the signer of the certificate at your own personal account.

 

Browsers keep a list of certificate authorities built-in, and verify locally a valid signed certificate, no need to connect to the CA itself.

 

Link to comment
11 hours ago, Frank1940 said:

Then you will have to figure out how to convince the Browser that you really want to have access to this site

 

The current implementation, at least with Chrome, is the display of a green padlock when visiting a https site, while it says "not secure" when visiting a http site.

Google has plans to change that indication and make https display as the regular access (no more padlock), while a more prominent warning (red padlock) is given when http is used.

They will however not prohibit the access to http sites (there are still millions of them).

 

Link to comment
14 hours ago, bonienl said:

If the PC I am using to connect to unRAID is hijacked and some key-logger is installed, it really doesn't matter whether HTTP or HTTPS is used, they will "see" anyway what I am doing.

 

 

A key logger doesn't catch pasted passwords from a password manager, because they aren't pasted as key presses.

 

But DNS poisoning is an attack that just requires access to the network broadcast domain.

 

12 hours ago, John_M said:

But even when you have a valid certificate, if it can't be verified as being valid because the signing authority's responder doesn't respond you get an error!

 

The browser doesn't really need to visit the signing authority - but the reason it wants to is to check the certificate revocation list. Most SSL-based applications doesn't bother with certification revocations so they never contacts the CA. But depending on the information encoded in the certificate, web browsers normally wants that additional step of security.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...