48 replies to this topic

[Erik Slagter]

I mixed up with K9 mail. It claims to support client side authentication but it doesn't work.

 

If this works well, and if it's enforced correctly, I think it's a lot more secure than a password, it may save people from setting up a VPN.

 

On the other hand, enigma and the streamproxy don't know about client certs.

[Erik Slagter]

Erik Slagter, on 19 Apr 2014 - 13:06, said:
But does it enforce either:

- the cert + cn to be known
- the cert to be signed by a common ca

It trusts certs issued by any of the signers having their certs in /etc/enigma2/ca.pem

You have to fill that file yourself though atm, e.g. using this list:
Exported Mozilla root CAs

In my case, I added CAcert for testing.

This is sufficient, indeed. Either a trusted CA or your own CA is fine.

[SpaceRat]

If this works well, and if it's enforced correctly, I think it's a lot more secure than a password, it may save people from setting up a VPN.

It's client cert plus login/pass.
I might add an option for cert auth to bypass login/pass though ...

On the other hand, enigma and the streamproxy don't know about client certs.

The stream proxy doesn't know anything about https either.
But as long as you do not need the access for streaming, it's sufficient.

[Erik Slagter]

If this works well, and if it's enforced correctly, I think it's a lot more secure than a password, it may save people from setting up a VPN.

It's client cert plus login/pass.
I might add an option for cert auth to bypass login/pass though ...

That's not what I meant, but it would be nice to be able to choose.

On the other hand, enigma and the streamproxy don't know about client certs.

The stream proxy doesn't know anything about https either.
But as long as you do not need the access for streaming, it's sufficient.

Yes exactly. All of the streaming functionality really should have been in the webif interface in the first place, it should never have been in an external proxy or in enigma2. And then you would be able to stream over https with authentication as well. But that station has been passed long ago unfortunately.

Can you tell me why the webif insists on supplying an .m3u file instead of the stream itself? Both mplayer (linux) and android don't understand m3u, while they do understand an mpeg video stream over http, so if the m3u step is skipped, it just works (android needs vplayer or vlc).

Edited by Erik Slagter, 19 April 2014 - 12:37.

[MiLo]

To stream from the webif directly, it should just handover the socket handle to the C++ code. It should be possible, is there a "request.file_no()" or something similar?

You could also just open an internal client socket to the proxy and "pump" the data along to the request's socket (close the incoming part of the request socket with "shutdown" to save a bit of resources), that wouldn't be much of a burden to the cpu anyway.

[Erik Slagter]

Ouch, I'd rather not...

 

How about alternative #3, for some of us that are not completely familiar with enigma, the webif could fork/exec an external program and pass on the socket's file descriptor. That has the same problem as #1 though, it will not add https.

[MiLo]

It's client cert plus login/pass.
I might add an option for cert auth to bypass login/pass though ...

That would be good.

It makes sense to not have to supply credentials on the local network. Only forward the HTTPS port with client cert authentication, and with that, you'd be as safe as with VPN or SSH.

The login doesn't add anything on top of that, the client certificate is a much safer way of logging in, and it requires authentication even before the HTTP server itself is involved.

[SpaceRat]

It's client cert plus login/pass.
I might add an option for cert auth to bypass login/pass though ...

That would be good.

It makes sense to not have to supply credentials on the local network. Only forward the HTTPS port with client cert authentication, and with that, you'd be as safe as with VPN or SSH.

The login doesn't add anything on top of that, the client certificate is a much safer way of logging in, and it requires authentication even before the HTTP server itself is involved.

Well, if you use the cacert.pem I was pointing at and a client cert issued by one of those Root CAs (StartSSL, CAcert, ....), ANYONE with a valid certificate from that Root CA could sign in.
We would only know WHO signed in.

Client cert is only enough if the only root CA allowed is your own one and not for example StartSSL, CAcert, ...

And at the moment, client cert auth is rather useless:
Chrome on Android theoretically supports client cert auth, but the used layer was broken in Android 3.0 and still is at least up to Android 4.1.2.
Dreamdroid uses the same layer ...

And even if that layer would work again, Android still requires the user to change the unlock security to anything more protectice than wiping, which most users consider annoying.

Firefox für Android and the Android Browser have working client cert auth, but only Firefox can offer this without changing the lock screen.

[MiLo]

Well, if you use the cacert.pem I was pointing at and a client cert issued by one of those Root CAs (StartSSL, CAcert, ....), ANYONE with a valid certificate from that Root CA could sign in.

That wouldn't do much useful indeed. You'd want to assign rights to specific users, not complete CA's (unless you're your own CA).

Certificate login will supply you with strong authentication. It would be a waste not to use that for authorization as well. Much safer and even much more convenient once you've set it up than passwords.

Certificate login would for example allow you to take a smartcard with you, and use that in an environment like an internet cafe, without fear of your box being compromized. Though people could still eavesdrop on your data there, they won't be able to steal your credentials.

Edited by MiLo, 19 April 2014 - 18:22.