Seguridad en Internet

Resumen
Cuando se realizan pagos en Internet y acceso a sitios Web que requieren certificado,
intervienen dos protocolos seguros SSL y SET, ofreciendo confidencialidad,
identificación, integridad e identificar tanto al cliente como al servidor.

Palabras clave

Protocolo, SSL, SET, cifrado, autenticación, integridad, cliente, servidor, pago.

1 Introducción
Hay ocasiones en las que se hace necesario recibir/enviar información sensible
desde/a un servidor de Web, ya sea información confidencial, datos de personal,
nóminas, etc.

No vale con restringir el acceso mediante claves de acceso o procedimientos

similares, además la información que viaja desde/a un servidor de Web debe ir cifrada,
para evitar escuchas se pone de manifiesto la necesidad de asegurar mediante algún
mecanismo la intimidad y la integridad en las sesiones con el Servidor Web.[ALVe]

Para ello surgen dos protocolos que se comentan a continuación.

2 Protocolo SSL
SSL (Secure Sockets Layer) fue diseñado y propuesto en 1994 por Netscape
Communications Corporation junto con su primera versión del Navigator como un
protocolo para dotar de seguridad a las sesiones de navegación a través de Internet.
Sin embargo, no fue hasta su tercera versión, conocida como SSL v3.0 que alcanzó su
madurez, superando los problemas de seguridad y las limitaciones de sus
predecesores.

En su estado actual proporciona los siguientes servicios:

 Cifrado de datos: la información transferida, aunque caiga en manos de un

atacante, será indescifrable (confidencialidad).

1
  Autenticación de servidores: el usuario puede asegurarse de la identidad del
servidor al que se conecta.
 Integridad de mensajes: se impide que modificaciones intencionadas o
accidentales en la información mientras viaja por Internet pasen inadvertidas.
 Autenticación de cliente: permite al servidor conocer la identidad del usuario,
con el fin de decidir si puede acceder a ciertas áreas protegidas.

2.1 ¿Cómo funciona SSL?

Cuando un navegador solicita una página a un servidor seguro, ambos

intercambian una serie de mensajes para negociar las mejoras de seguridad. Este
protocolo sigue las siguientes fases (de manera muy resumida):

 La fase Hola, usada para ponerse de acuerdo sobre el conjunto de algoritmos

para garantizar la confidencialidad e integridad y para la autenticación mutua.
El navegador le informa al servidor de los algoritmos que posee disponibles.

 La fase de autenticación, en la que el servidor envía al navegador su certificado

x.509v3 que contiene su clave pública y solicita a su vez al cliente su
certificado X.509v3 (sólo si la aplicación exige la autenticación de cliente).

 La fase de producción de clave de sesión, en la que el cliente envía al servidor

una clave maestra a partir de la cual se generará la clave de sesión para cifrar
los datos intercambiados posteriormente mediante el algoritmo de cifrado
simétrico acordado en la fase 1. El navegador envía cifrada esta clave maestra
usando la clave pública del servidor que extrajo de su certificado en la fase 2.

 La fase Fin, en la que se verifica mutuamente la autenticidad de las partes

implicadas y que el canal seguro ha sido correctamente establecido. Una vez
finalizada, ya se puede comenzar la sesión segura.

De ahí en adelante, durante la sesión segura abierta, SSL proporciona un canal de

comunicaciones seguro entre los servidores Web y los clientes (los navegadores) a
través del cual se intercambiará cifrada la información (URL, formularios, cookies, ...).

2.2 Ventajas de SSL

SSL v3.0 goza de gran popularidad y se encuentra ampliamente extendido en

Internet, ya que viene soportado por los dos principales navegadores del mercado,
Netscape Navigator 3.0 ó superior así como por Internet Explorer 3.0 ó superior.

SSL proporciona un canal de comunicaciones seguro entre los servidores web

y los clientes (los navegadores), pero su uso no se limita a la transmisión de páginas
web. Al encontrarse entre los niveles de transporte y de aplicación, potencialmente
SSL puede servir para dar seguridad a otros servicios, como FTP, correo, telnet, etc.

El usuario no necesita realizar ninguna acción especial para invocar el

protocolo SSL, basta con seguir un enlace o abrir una página cuya dirección empieza
por HTTPs://. El navegador se encarga del resto.

2
2.3 Limitaciones y Problemas

Debido a la limitación de exportación del gobierno de los Estados Unidos sobre

los productos criptográficos, las versiones de los navegadores distribuidas legalmente
más allá de sus fronteras operan con nada más que 40 bits de longitud de clave.
Claves tan cortas facilitan los ataques de fuerza bruta.

Es importante recalcar que SSL sólo garantiza la confidencialidad e integridad

de los datos en tránsito, ni antes ni después. Por lo tanto, si se envían datos
personales al servidor, entre ellos el número de tarjeta de crédito, número de la
seguridad social, DNI, etc., SSL solamente asegura que mientras viajan desde el
navegador hasta el servidor no serán modificados ni espiados.

SSL solamente se utiliza para comunicaciones seguras en WWW.

El protocolo SSL se trata de un sistema de seguridad ideado para acceder a un

servidor, garantizando la confidencialidad de los datos mediante técnicas de cifrado
modernas.

El protocolo SSL sólo afecta a la comunicación cliente vendedor; la

comunicación vendedor-banco se realiza mediante protocolos privados.

SSL no garantiza los requerimientos de seguridad en su totalidad pero aporta

las siguientes características:

 Confidencialidad. Mediante el uso de la encriptación.

 Integridad. Se garantiza que los datos recibidos son exactamente iguales a los
datos enviados
 Autenticación. El vendedor se autentifica utilizando un certificado digital emitido
por una empresa llamada “autoridad certificadora”
 No Repudio. Este requisito no esta garantizado

3 Protocolo SET (Secure Electronic Transaction)

Como se puede observar de las características anteriores, el protocolo SSL

garantiza la seguridad siempre que exista una confianza mutua entre comprador y
vendedor. Con el objetivo de aumentar la seguridad, Visa y Mastercard crearon en
mayo de 1997 el protocolo SET.
Las principales diferencias entre SSL y SET estriban en que en este protocolo
se definen tres entidades (cliente, vendedor y banco) y un protocolo de
comunicaciones estándar entre vendedor y banco . En SET cada una de las entidades
debe certificarse antes de realizar cualquier transacción y todos los mensajes quedan
firmados digitalmente de manera que no puedan ser modificados posteriormente,
eliminado la posibilidad de repudio.

3.1 El protocolo SET

En relación a los requerimientos de seguridad tenemos:

3
  Confidencialidad. Igual que en SSL, los datos van encriptados y no pueden
ser interpretados por cualquier persona ajena a la transacción. SET
aumenta la privacidad de la comunicación al impedir que el vendedor tenga
acceso a los datos bancarios del cliente y que el banco no pueda acceder a
los datos de la compra.
 Integridad. Los datos enviados no pueden ser alterados ni durante la
comunicación ni después ya que han sido firmados digitalmente.
 Autenticación. Tanto el banco, como el vendedor y el cliente deben estar
certificados. En SSL únicamente se certifica al vendedor.
 No Repudio. La firma digital puede servir como prueba de la transacción,
por lo que ninguna de las partes puede negar haber participado en ella.
Aunque técnicamente se pueda demostrar que la compra se produjo,
legalmente el cliente siempre tendrá el derecho a negar su participación en
la compra.

3.2 Cómo funciona SET

El proceso subyacente en una transacción SET típica funciona de forma muy

parecida a una transacción convencional con tarjeta de crédito:

Decisión de compra del cliente. El protocolo SET se inicia cuando el comprador pulsa
el botón de Pagar o equivalente.

Arranque de la cartera. El servidor del comerciante envía una descripción del pedido
que despierta a la aplicación cartera del cliente.

Transmisión cifrada de la orden de pago. Se crean dos mensajes y se envían al

comerciante. El primero, la información del pedido, mientras que el segundo contiene
las instrucciones de pago del cliente para el banco adquiriente. Este mecanismo
reduce el riesgo de fraude y abuso, ya que ni el comerciante llega a conocer el número
de tarjeta de crédito empleado por el comprador, ni el banco se entera de los hábitos
de compra de su cliente.

Envío de la petición de pago al banco del comerciante. Se envían al banco adquiriente

la petición de autorización junto con las instrucciones de pago (que el comerciante no
puede examinar, ya que van cifradas con la clave pública del adquiriente).

Validación del cliente y del comerciante por el banco adquiriente.

Autorización del pago por el banco emisor del cliente. El banco emisor verifica todos
los datos de la petición y si todo está en orden y el titular de la tarjeta posee crédito,
autoriza la transacción.

Envío al comerciante de un testigo de transferencia de fondos. En cuanto el banco del

comerciante recibe una respuesta de autorización del banco emisor, genera y firma
digitalmente un mensaje de respuesta de autorización, convenientemente cifrada, la
cual se la hace llegar al comerciante.

4
Envío de un recibo a la cartera del cliente. Cuando el comerciante recibe la respuesta
de autorización de su banco, verifica las firmas digitales y entrega al cliente un recibo
de la compra, como justificante de compra.

Entrega del testigo de transferencia de fondos para cobrar el importe de la transacción.

El comerciante genera una petición de transferencia a su banco, confirmando la
realización con éxito de la venta. Como consecuencia, se produce el abono en la
cuenta del comerciante.

Cargo en la cuenta del cliente. A su debido tiempo, la transacción se hace efectiva

sobre la cuenta corriente del cliente.

El protocolo definido por SET especifica el formato de los mensajes, las

codificaciones y las operaciones criptográficas que deben usarse. No requiere un
método particular de transporte, de manera que los mensajes SET pueden
transportarse sobre HTTP en aplicaciones Web, sobre correo electrónico o cualquier
otro método.

En su estado actual SET solamente soporta transacciones con tarjeta de

crédito/débito, y no con tarjetas monedero. Se está trabajando en esta línea para
extender el estándar de manera que acepte nuevas formas de pago. Al mismo tiempo
se están desarrollando proyectos para incluir los certificados SET en las tarjetas
inteligentes, de tal forma que el futuro cambio de tarjetas de crédito a tarjetas
inteligentes pueda incorporar el estándar SET.

¿ Cómo puede saber el cliente que está realizando una compra segura ?

En las compras con SSL, el cliente accederá a un “centro comercial virtual”

mediante un navegador Internet y seleccionará los productos que desea adquirir.

Posteriormente, entrará en una página donde se le pedirán sus datos

personales y bancarios, el más importante de ellos es el PIN de la tarjeta de crédito.

Antes de enviar los datos hay que fijarse si estamos conectando con un
servidor seguro; esto se puede comprobar mirando el icono del “candado” que aparece
en la parte superior del navegador. Si está cerrado significa que la comunicación se
realizará mediante las técnicas de encriptación SSL y que el servidor esta certificado
por Verisign. En caso contrario el navegador mostrará un mensaje avisando que la
comunicación no es segura.

4 Conclusiones
Las claves para saber si una persona o cliente hace una compra segura, es saber si
se trabaja con un protocolo seguro, entre ellos SSL o SET, para ello el cliente
accederá a un “centro comercial virtual” mediante el navegador seleccionando
productos. Cuando en la página se solicita los datos personales, bancarios y pide el
pin de la tarjeta de crédito, se debe observar si se está conectando a un servidor
seguro, comprobando si el icono del candado que aparece en la parte superior del
candado sino es mejor no realizar esa compra. Si está cerrado ese candado significa
que la comunicación se está aplicando mediante técnicas de encriptación SSL y que el
servidor está certificado, en caso contrario avisará si la comunicación no es segura.

5
Bibliografía
Marañón, Álvarez. Seguridad SLL,(2010), extraído el 2 de Abril desde
http://www.idg.es/iworld/articlo.asp?id=68235&sec=iworld

Set en Internet, (2010), extraído el 2 de Abril desde http://www.setco.org

The SSL protocol, (2010), extraído el 7 de Abril desde

http://www.netscape.com/eng/ssl3/ssl-toc.html
Verisign Secre Site Services, extraído el 7 de Abril desde http://www.verisign.com