LUK
25-10-2010, 11:07
A estas alturas todo el mundo está familiarizado con SSL, es la capa de seguridad mediante cifrado que incorpora HTTP para proteger las comunicaciones.
Bajo las siglas SSL se encuentra un complejo entramado de longitudes, algoritmos y tipos de certificados. La forma en la que se combinan estos parámetros hace que un servidor ofrezca una conexión SSL mas o menos robusta. Como tantas cosas en el mundo de la seguridad, se cumple el axioma: mas robusto = mas inversión.
Teóricamente y sobre el papel la banca online debería ser ejemplo a la hora de implementar SSL en sus servicios por dos motivos:
1- Son entidades que manejan mucha inversión
2- El tipo de actividad a la que se dedican requiere todas las garantías
Pero ... ¿Es así? Hemos realizado un estudio sobre los principales portales de banca online Españoles analizando diversos parámetros para evaluar la robustez del servicio.
Criterios evaluados:
Soporte a SSL v2: Se puntúa como Bien no dar soporte a negociaciones SSL v2 (obsoletas y con numerosos vectores inseguros) y Mal si el servidor lo admite
Tipo de certificado: Puntúa como Mal tener un certificado SSL normal y corriente (ver post sobre Agencia Pituitaria (http://www.securitybydefault.com/2009/06/fraude-online-con-firma-digital-y-ssl.html)) y bien tener un certificado con Validación extendida (http://www.securitybydefault.com/2009/06/certificados-digitales-con-validacion.html) (mucho mas riguroso y caro)
Longitud de la clave RSA del certificado: Puntúa como Mal tener un certificado de 1024 o menos y Bien tener 2048
Soporte de algoritmos 'débiles': Se entiende por algoritmo débil aquel que cuya longitud de clave es 56 o 64 bits y puntúa como Mal admitir esos algoritmos para cifrar la conexión y Bien no hacerlo
Los resultados (click en la imagen para mayor definición):
http://1.bp.blogspot.com/_fWA7DVpD2eo/TMR4AVoVX0I/AAAAAAAAAjQ/xLXHl_NNWig/s400/bancos-ssl.jpg (http://1.bp.blogspot.com/_fWA7DVpD2eo/TMR4AVoVX0I/AAAAAAAAAjQ/xLXHl_NNWig/s1600/bancos-ssl.jpg)
Destaca sobremanera el caso del BBVA, que ha puntuado en todo Mal, incluso sospecho que el hecho de que la longitud de su clave pública sea de 1023 y no 1024 se deba a un bug en la generación del CSR (hay documentados bugs de ese tipo en algunas plataformas).
Por contra, hay que destacar muy positivamente al Banco Popular, Bankinter, Deutsche Bank y Bancaja que sacan un Sobresaliente merecido.
Por último mencionaré de soslayo algo que me llama poderosamente la atención. En el mundo bancario existe una normativa llamada PCI-DSS (http://es.pcisecuritystandards.org/minisite/en/index.html) que especifica niveles de seguridad y buenas prácticas en las entidades bancarias. En el punto 4.1 dice: 'Utilice criptografía y protocolos de seguridad sólidos como SSL/TLS o IPSEC para salvaguardar los datos confidenciales de los titulares de las tarjetas durante su transmisión a través de redes públicas abiertas' Y mas concretamente: 'Controle que se implemente la solidez de cifrado adecuada para la metodología que se utiliza'
Esto, que suena tan vago e inconcreto, por lo general (http://www.sslshopper.com/article-ssl-certificates-and-pci-compliance.html) se suele interpretar como el NO uso de SSL v2 y el NO uso de algoritmos débiles.
Ficha técnica
Urls analizadas:
Banco Pastor https://pastornetparticulares.bancopastor.es/
Banco Popular https://www2.bancopopular.es
Banco Santander https://www.gruposantander.es
Banesto https://extranet.banesto.es
Bankinter https://www.bankinter.com/
BBVA https://www.bbva.es
Deutsche Bank https://ww3.deutsche-bank.es
Citibank https://www.production.citibank.es
ING https://www.ingdirect.es/
Bancaja https://www.bancaja.es/
Caja España https://www.cajaespana.net/
Caja Madrid https://oi.cajamadrid.es/
La Caixa http://portal.lacaixa.es/
Metodología empleada:
Verificación SSL v2:
openssl s_client -ssl2 -connect servidor:443
Tipo de certificado (Normal / EV):
Cualquier navegador actual (Chrome, Firefox, IE)
Longitud clave pública:
openssl s_client -connect servidor:443
Soporte de algoritmos débiles:
openssl s_client -cipher LOW:EXP -connect servidor:443
Publicado por Yago Jesus en http://www.securitybydefault.com/2010/10/bancos-y-ssl-quien-aprueba.html
Bajo las siglas SSL se encuentra un complejo entramado de longitudes, algoritmos y tipos de certificados. La forma en la que se combinan estos parámetros hace que un servidor ofrezca una conexión SSL mas o menos robusta. Como tantas cosas en el mundo de la seguridad, se cumple el axioma: mas robusto = mas inversión.
Teóricamente y sobre el papel la banca online debería ser ejemplo a la hora de implementar SSL en sus servicios por dos motivos:
1- Son entidades que manejan mucha inversión
2- El tipo de actividad a la que se dedican requiere todas las garantías
Pero ... ¿Es así? Hemos realizado un estudio sobre los principales portales de banca online Españoles analizando diversos parámetros para evaluar la robustez del servicio.
Criterios evaluados:
Soporte a SSL v2: Se puntúa como Bien no dar soporte a negociaciones SSL v2 (obsoletas y con numerosos vectores inseguros) y Mal si el servidor lo admite
Tipo de certificado: Puntúa como Mal tener un certificado SSL normal y corriente (ver post sobre Agencia Pituitaria (http://www.securitybydefault.com/2009/06/fraude-online-con-firma-digital-y-ssl.html)) y bien tener un certificado con Validación extendida (http://www.securitybydefault.com/2009/06/certificados-digitales-con-validacion.html) (mucho mas riguroso y caro)
Longitud de la clave RSA del certificado: Puntúa como Mal tener un certificado de 1024 o menos y Bien tener 2048
Soporte de algoritmos 'débiles': Se entiende por algoritmo débil aquel que cuya longitud de clave es 56 o 64 bits y puntúa como Mal admitir esos algoritmos para cifrar la conexión y Bien no hacerlo
Los resultados (click en la imagen para mayor definición):
http://1.bp.blogspot.com/_fWA7DVpD2eo/TMR4AVoVX0I/AAAAAAAAAjQ/xLXHl_NNWig/s400/bancos-ssl.jpg (http://1.bp.blogspot.com/_fWA7DVpD2eo/TMR4AVoVX0I/AAAAAAAAAjQ/xLXHl_NNWig/s1600/bancos-ssl.jpg)
Destaca sobremanera el caso del BBVA, que ha puntuado en todo Mal, incluso sospecho que el hecho de que la longitud de su clave pública sea de 1023 y no 1024 se deba a un bug en la generación del CSR (hay documentados bugs de ese tipo en algunas plataformas).
Por contra, hay que destacar muy positivamente al Banco Popular, Bankinter, Deutsche Bank y Bancaja que sacan un Sobresaliente merecido.
Por último mencionaré de soslayo algo que me llama poderosamente la atención. En el mundo bancario existe una normativa llamada PCI-DSS (http://es.pcisecuritystandards.org/minisite/en/index.html) que especifica niveles de seguridad y buenas prácticas en las entidades bancarias. En el punto 4.1 dice: 'Utilice criptografía y protocolos de seguridad sólidos como SSL/TLS o IPSEC para salvaguardar los datos confidenciales de los titulares de las tarjetas durante su transmisión a través de redes públicas abiertas' Y mas concretamente: 'Controle que se implemente la solidez de cifrado adecuada para la metodología que se utiliza'
Esto, que suena tan vago e inconcreto, por lo general (http://www.sslshopper.com/article-ssl-certificates-and-pci-compliance.html) se suele interpretar como el NO uso de SSL v2 y el NO uso de algoritmos débiles.
Ficha técnica
Urls analizadas:
Banco Pastor https://pastornetparticulares.bancopastor.es/
Banco Popular https://www2.bancopopular.es
Banco Santander https://www.gruposantander.es
Banesto https://extranet.banesto.es
Bankinter https://www.bankinter.com/
BBVA https://www.bbva.es
Deutsche Bank https://ww3.deutsche-bank.es
Citibank https://www.production.citibank.es
ING https://www.ingdirect.es/
Bancaja https://www.bancaja.es/
Caja España https://www.cajaespana.net/
Caja Madrid https://oi.cajamadrid.es/
La Caixa http://portal.lacaixa.es/
Metodología empleada:
Verificación SSL v2:
openssl s_client -ssl2 -connect servidor:443
Tipo de certificado (Normal / EV):
Cualquier navegador actual (Chrome, Firefox, IE)
Longitud clave pública:
openssl s_client -connect servidor:443
Soporte de algoritmos débiles:
openssl s_client -cipher LOW:EXP -connect servidor:443
Publicado por Yago Jesus en http://www.securitybydefault.com/2010/10/bancos-y-ssl-quien-aprueba.html