Como comentábamos en otros posts, OAuth nos ofrece numerosas posibilidades a la hora de implementar la autorización y autenticación en nuestras aplicaciones.
En esta entrada vamos a comentar una extensión que está siendo definida actualmente y que amplía nuestra perspectiva a la hora de utilizar este protocolo.
Hablamos de OAuth WRAP (OAuth Web Resource Authorization Profiles), la cual nació para intentar simplificar a OAuth, eliminando sus procesos de firma y reemplazándolas por tokens de corta duración sobre SSL/TLS.
WRAP no pretende sustituir a OAuth, pero sí añadir nuevas características que completen y desarrollen elementos de los cuales carece el protocolo en su versión original.
Esta extensión permite la delegación de la autorización de recursos protegidos a una o más autoridades de confianza. Los Clientes que desean acceder a un Recurso Protegido primero obtienen autorización de un Servidor de Autorización, enviando para ello unas credenciales y perfiles determinados.
Una vez autorizados, el Cliente obtiene un Token de Acceso (Access Token) firmado digitalmente que podrá ser reemitido en caso de ser necesario y que permitira, como su nombre indica, acceder a los recursos protegidos.
OAuth WRAP define distintos perfiles que especifican las credenciales que deben enviarse al Servidor de Autenticación y cómo las obtendrá el Cliente. Es posible especificar perfiles propios e incluso adoptar los que ya están establecidos. En posteriores posts os comentaremos algunos de ellos.
En la comunidad de desarrolladores de PAPI estamos trabajando en la definición del protocolo PAPI v1.1, que traerá algunas mejoras sobre la versión inicial, que ya iremos desvelando poco a poco en este blog.
Una de estas mejoras es la inclusión del parámetro opcional PAPIOPOA en un mensaje ATTREQ, el cual corresponde a una petición de atributos por parte de un PoA o GPoA. Cuando un proveedor de identidad PAPI recibe este tipo de mensaje, en el caso de que el usuario no se hubiese autenticado previamente, necesitará realizar la autenticación del usuario antes de generar la respuesta al GPoA/PoA.
De esta forma, el mensaje ATTREQ queda definido con la siguiente URL:
Mensaje ATTREQ
Donde,
- ATTREQ: contiene el ID del GPoA/PoA que ha realizado la petición.
- PAPIPOAREF: es un valor que establece el emisor del mensaje y que le será devuelto en la respuesta.
- PAPIPOAURL: es la URL del emisor que ha generado la redirección al proveedor de identidad.
- PAPIOPOA: en el caso de que el emisor del mensaje sea un GPoA y haya enviado el mensaje tras recibir solicitud de credenciales por parte de un PoA, este parámetro opcional incluirá la URL de dicho PoA que generó el mensaje al GPoA.
La principal utilidad de PAPIOPOA es facilitar la política de emisión de atributos de los proveedores de identidad. Consideremos el siguiente escenario:
Escenario PAPIOPOA
Como vemos, cada vez que el AS recibe un mensaje ATTREQ emitido por el GPoA, tendrá que emitir todos los atributos que podrían requerir cualquiera de los PoAs que están conectados con dicho GPoA.
Sin embargo, si en el mensaje ATTREQ recibe el parámetro PAPIOPOA, podremos saber cual fue el PoA que hizo la petición al GPoA y emitir sólo los atributos que dicho PoA necesita.
Además, este nuevo parámetro facilita enormemente la generación de unas estadísticas de acceso, ya que sabremos a qué recurso protegido intenta acceder un determinado usuario.
La Electronic Frontier Foundation (EFF) está trabajando en un interesantísimo proyecto sobre privacidad: Panopticlick. Éste pretende investigar si nuestros navegadores, aun no emitiendo información de IP o a través de cookies, pueden ser fácilmente identificable por terceras aplicaciones web.
La información que proporciona el navegador, como la versión del sistema operativo, los plug-ins que tiene activado, las fuentes o tipos de letra que soporta, proporcionan una huella digital que podría servir para identificar nuestro puesto informático. De hecho, esta técnica se conoce como Device fingerprint y se sabe que es una de las técnicas que utilizan las empresas de publicidad en Internet, a la hora de personalizarnos los anuncios a mostrarnos.
Como vemos, el objetivo de esta investigación es obtener una base de datos anónima de navegadores de cara a saber si es posible o no identificar únicamente nuestro navegador con la información que envía y hasta que punto debería ser corregido este asunto.
Yo he probado con mi navegador Safari 4 y Firefox 3.5 y en ambos me ha informado que con su actual base de datos de más de 420.000 navegadores diferentes, podrían identificarlos unívocamente. Parece que la privacidad en Internet sigue siendo algo por lo que luchar, ¿no?
Últimamente me he visto envuelto en diferentes debates sobre si era seguro o no usar certificados con capacidades SSL, no sólo para asegurar conexiones TCP y/o autenticar servidores, sino también para firmar metadatos o aserciones.
El escenario en el que nos encontramos es el indicado en la figura, en el cual un cliente realiza conexiones HTTPS contra un IdP (Proveedor de Identidad) para acceder a un sistema SSO y por ende a recursos protegidos. Dónde al logarse el cliente con éxito, el IdP genera una aserción sobre quién es el cliente y qué atributos posee, el IdP firma esta aserción con el mismo certificado que se ha usado para establecer la conexión HTTPS.
Escenario
El problema, o mejor dicho, el origen de las inquietudes reside en el uso del mismo certificado para la conexión HTTPS y para la firma de la aserción o de cualquier otro tipo de metadatos, y en el cual confían los SPs (proveedor de servicio) que han establecido relaciones de confianza con el IdP.
Pues bien, estas inquietudes se basan en la creencia incierta de que un servidor web firmará alegremente cualquier cosa presentada por el cliente en el ‘random binary blob‘ durante el SSL-handshake. Si esto fuese cierto un atacante tendría la capacidad de enviar como ‘random binary blob‘ una aserción falsa, que al ser firmada por el certificado x509 en el que confían los SPs, le diese la capacidad de acceder a recursos a los cuales no tiene acceso.
Esto es totalmente falso, ya que bajo ninguna circunstancia un servidor web firmará datos arbitrarios presentados por un cliente. Para aclarar esto voy a explicar que datos presenta el cliente al servidor y que son susceptibles de ser firmados.
Durante el handshake del protocolo TLS/SSL se genera el master secret, el cual es un secreto compartido entre el cliente y el servidor, de 48 bytes y que es usado como clave simétrica para proteger la sesión. Este master secret, se genera mediante la siguiente función:
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random);
Donde PRF es la Pseudoroandom Function elegida de la cipher-suite- especificada en fases previas del handshake, la cual es una función basada en HMAC, que no usa en ningún momento la clave privada del certificado.
El pre_master_secret, es una cadena de 48 bytes enviada por el cliente al servidor y que es lo que nos interesa en este caso, ya que representa los únicos datos que el servidor cifra de forma «alegre».
La cadena «master secret» es una constante con dicho valor.
Y por último las cadenas ClientHello.random y ServerHello.random son dos blob de 28 bytes, el primero enviado por el cliente en la fase ClientHello del handshake y el segundo enviado por el servidor en la fase ServerHello.
Como he dicho anteriormente, nos interesa el pre_master_secret, ya que esta cadena son 48 bytes, de los cuales 46 son generados aleatoriamente por el cliente y 2 indican el protocolo. Estos 48 bytes son cifrados con la clave pública del servidor. Y es este cifrado el punto que ha generado tanta controversia.
Pues bien, al cifrarse estos datos con la clave pública del servidor, es este servidor el único que puede descifrar y por tanto entender estos datos, ya que es el único en posesión de la clave privada correspondiente.
Con esto, si un cliente malintencionado en vez de generar 46 bytes aleatorios, introduce la aserción falsa, lo que obtendría es un mensaje cifrado que sólo puede leer quien posea la clave privada del servidor. La cual no está en posesión de los SPs, ya que estos sólo necesitan la clave pública, para comprobar la firma de las aserciones.
Como conclusión, decir que podemos estar seguros de usar el mismo certificado x509 tanto para asegurar sesiones con TLS/SSL como para firmar aserciones o metadatos ya que según la especificación del protocolo TLS los datos que un servidor cifra «alegremente», sólo los puede descifrar él.
Por último decir que separar por roles el uso de claves privadas de los certificados x509, es decir, usar una para TLS y otra para firmar aserciones y/o metadatos, es una buena práctica de seguridad. Ya que aunque TLS ha sido diseñado para resistir ataques contra autenticación y firmado, la historia nos ha demostrado muchas veces que confiar en la calidad de un algoritmo o protocolo y en su implementación debería evitarse en la medida de lo posible.