... | @@ -10,15 +10,15 @@ For obvious reasons we won't take into consideration tunnelling solutions like V |
... | @@ -10,15 +10,15 @@ For obvious reasons we won't take into consideration tunnelling solutions like V |
|
They are all difficult to set up (from a user point of view) and this just isn't the right use-case for a VPN.
|
|
They are all difficult to set up (from a user point of view) and this just isn't the right use-case for a VPN.
|
|
|
|
|
|
Here we are left with few choices:
|
|
Here we are left with few choices:
|
|
* SSL
|
|
* ~~SSL~~
|
|
* TLS
|
|
* TLS
|
|
* DTLS
|
|
* DTLS
|
|
|
|
|
|
The fun part is that all these options are not so different one from the other.
|
|
The fun part is that all these options are not so different one from the other.
|
|
TLS is an evolution of SSL, and DTLS is TLS over UDP (very simplified, ok, but you got it).
|
|
TLS is an evolution of SSL, and DTLS is TLS over UDP (very simplified, ok, but you got it).
|
|
So there actually is no choice in the matter, which is why attacks like [BEAST](http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack) or [CRIME](http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29) have suck a huge impact and made everyone so afraid.
|
|
So there actually is no choice in the matter, which is why attacks like [BEAST](http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack) or [CRIME](http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29) had such a huge impact and made everyone so afraid.
|
|
|
|
|
|
The good news is that these protocols have been thoroughly tested and are considered secure by all the experts.
|
|
The good news is that these protocols have been thoroughly tested and are considered enough secure by all the experts.
|
|
|
|
|
|
And if you need just the encryption, these are perfectly fine.
|
|
And if you need just the encryption, these are perfectly fine.
|
|
|
|
|
... | @@ -28,18 +28,18 @@ But what are the differences? |
... | @@ -28,18 +28,18 @@ But what are the differences? |
|
|
|
|
|
SSL is the older one, from version 1.0, 2.0 (both unused and insecure) to 3.0 (insecure, still used).
|
|
SSL is the older one, from version 1.0, 2.0 (both unused and insecure) to 3.0 (insecure, still used).
|
|
|
|
|
|
This protocol supports encrption with a single X.509 certificate, and user identification. multiple authentication schemes are supported, so passwords or certificates are fine.
|
|
This protocol supports encryption with a single X.509 certificate, and user identification. Multiple authentication schemes are supported, so passwords or certificates are fine.
|
|
|
|
|
|
As [wikipedia](http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_3.0) puts it, TLS 1.0 is actually better, but its still widely used.
|
|
As [wikipedia](http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_3.0) puts it, TLS 1.0 is actually better, but its still widely used.
|
|
|
|
|
|
One of the main drawbacks of SSL is that it does not play nicely with virtual hosts -- that is, trying to have multiple certificates on the same listening port. Just use TLS if you can.
|
|
One of the main drawbacks of SSL (aside from the many security problems)is that it does not play nicely with virtual hosts -- that is, trying to have multiple certificates for different domains on the same listening port. Just use TLS.
|
|
|
|
|
|
This protocol has recently been deprecated and is being phased out in favour of TLS
|
|
This protocol has recently been deprecated and is being phased out in favour of TLS
|
|
|
|
|
|
### TLS
|
|
### TLS
|
|
|
|
|
|
As the evolution of SSL, it has better key-derivation functions, supports virtual hosts, and has a better general security.
|
|
As the evolution of SSL, it has better key-derivation functions, supports virtual hosts, and has a better general security.
|
|
Attacks are recently starting to target TLS, too (POODLE), but the protocol _per se_ seems secure
|
|
Attacks are recently starting to target TLS, too (POODLE), but the protocol _per se_ seems secure (now).
|
|
|
|
|
|
Still, we have 3 versions of it (1.0, 1.1 and 1.2), and the browser support for the last ones is pretty bad (getting better) :(
|
|
Still, we have 3 versions of it (1.0, 1.1 and 1.2), and the browser support for the last ones is pretty bad (getting better) :(
|
|
|
|
|
... | @@ -49,21 +49,21 @@ This is the version used for datagram-oriented connections (as the name implies) |
... | @@ -49,21 +49,21 @@ This is the version used for datagram-oriented connections (as the name implies) |
|
|
|
|
|
The versions here are the same as in the TLS, and the security is the same.
|
|
The versions here are the same as in the TLS, and the security is the same.
|
|
|
|
|
|
Over the years some encryption algorithms have been found weak or broken, and it's the job of the programmer or the system administrator to know which are the good one and which are not.
|
|
Over the years some encryption algorithms have been found to be weak or broken, and it's the job of the programmer or the system administrator to know which are the good ones and which are not.
|
|
|
|
|
|
### Auth problems
|
|
### Auth problems
|
|
|
|
|
|
Note that although all these protocols can manage users, those apis are rarely left accessible by an application server to the application.
|
|
Note that although all these protocols can manage users, those apis are rarely left accessible by an application server to the application.
|
|
|
|
|
|
That is a possible problem with Fenrir, too: its flexibility should encourage application servers to expose the right api calls, but at the moment no naming or API convention is up for that, so we are risking API naming incompatibilities, although applications are usually written for a specific application server, or follow unspoken standards (see HTTP webservers).
|
|
That is a possible problem with Fenrir, too: its flexibility should encourage application servers to expose the right api calls, but at the moment no naming or API convention is up for that, so we are risking API naming incompatibilities, although applications are usually written for a specific application server, or follow de facto standards (see HTTP webservers).
|
|
|
|
|
|
### QUIC & Curvecp & MinimaLT
|
|
### QUIC & Curvecp & MinimaLT
|
|
|
|
|
|
There area actually some protocols that deserve a page on their own, [CurveCP](CurveCP) and [QUIC](QUIC).
|
|
There area actually some protocols that deserve a page on their own, CurveCP and [QUIC](QUIC).
|
|
|
|
|
|
CurveCP is a nice alternative, but it has (IMHO) some inefficiencies. Doesn't do much for authentication (like TLS, &co) and gives the user a TCP-like stream (no messages/multiple streams like Fenrir).
|
|
CurveCP is a nice alternative, but it has (IMHO) some inefficiencies. Doesn't do much for authentication (like TLS, &co) and gives the user a TCP-like stream (no messages/multiple streams like Fenrir).
|
|
|
|
|
|
The author of CurveCP also participated on an other protocol, [MinimaLT](MinimaLT). You might want to check it out, it has interesting proposals.
|
|
The author of CurveCP also participated on an other protocol, MinimaLT. You might want to check it out, it has interesting proposals, but is too tightly tied with a single ECC algorithm.
|
|
|
|
|
|
## Authentication
|
|
## Authentication
|
|
|
|
|
... | @@ -77,22 +77,24 @@ The most common possibilities right now are: |
... | @@ -77,22 +77,24 @@ The most common possibilities right now are: |
|
|
|
|
|
### SSL/TLS
|
|
### SSL/TLS
|
|
|
|
|
|
We already discussed about this. It works, it's not really safe anymore, but the main problem is that you can only authenticate **before** the connection takes place.
|
|
We already discussed about this. It works, but the main problem is that you can only authenticate **before** the connection takes place.
|
|
And not all application servers then expose apis to get the user id or login.
|
|
And not all application servers then expose apis to get the user id or login.
|
|
|
|
|
|
### OAuth
|
|
### OAuth
|
|
|
|
|
|
Well, I'm [not a fan](OAuth Hate) of this one. Inefficient, with lots of places to screw up your implementation, totally incompatible with other implementations, useless application identification etc...
|
|
Well, I'm [not a fan](OAuth Hate) of this one. Inefficient, with lots of places to screw up your implementation, totally incompatible with other implementations, useless application identification etc...
|
|
|
|
|
|
Still, it can be used. It provides both user identification and (somewhat) authorization.
|
|
Still, it can be used. It provides both user identification and (somewhat) authorization. But you need an HTTP client/server on both endpoints.
|
|
|
|
|
|
|
|
OpenID-Connect is an authentication protocol and standardization layer on top of OAuth2. An authentication protocol on top of an authentication protocol. I think it tells enough of the story of this ~~protocol~~ framework
|
|
|
|
|
|
### Kerberos
|
|
### Kerberos
|
|
|
|
|
|
Most of you surely know this one, it's a safe and tested (version 5 at least...), standard and federated authentication protocol.
|
|
Most of you surely know this one, it's a safe and tested (version 5 at least...), standard and federated authentication protocol.
|
|
|
|
|
|
But it requires the client and the server to have synchronized clocks. Which is difficult or impossible on the Internet, and the protocol to synchronize clock itself is not always secure.
|
|
But it requires the client and the server to have synchronized clocks. Which is difficult or impossible on the Internet, and the protocol to synchronize clocks itself is rarely secure.
|
|
|
|
|
|
The good thing is that it's one of the first big token-based protocols, and it made a big and clear distinction between authentication server, service and client.
|
|
The good thing is that it's one of the first big token-based protocols, and it made a big and clear distinction between authentication server, service and client. Used in Active Directory.
|
|
|
|
|
|
### OpenID
|
|
### OpenID
|
|
|
|
|
... | @@ -110,4 +112,8 @@ Right now the best way to do authentication for your application seems to be TLS |
... | @@ -110,4 +112,8 @@ Right now the best way to do authentication for your application seems to be TLS |
|
|
|
|
|
Again, I'm not a huge fan of it, but assuming you have a cryptographer near you that will explain you why your OAuth implementation is hackable, it's usable.
|
|
Again, I'm not a huge fan of it, but assuming you have a cryptographer near you that will explain you why your OAuth implementation is hackable, it's usable.
|
|
|
|
|
|
|
|
TLS + OAuth means only one reliable connection, having to deal with the HTTP protocol, maintaining passwords and token security, without federation support.
|
|
|
|
|
|
Of course, Fenrir is supposed to solve this mess and half-done protocols and fuse them together :)
|
|
Of course, Fenrir is supposed to solve this mess and half-done protocols and fuse them together :)
|
|
|
|
|
|
|
|
---- |
|
|
|
\ No newline at end of file |