Portada
mis comunidades
otras secciones
#11:
#2 #4 Es que estáis pensando en SSL/TLS como un mecanismo únicamente de cifrado y no es sólo eso, también es un mecanismo que garantiza la identidad de los extremos y la integridad del mensaje.
Esto evita también por ejemplo (es solo un ejemplo eh, pero hay mil) que una extensión maliciosa del navegador pueda llevarte a "su propio google.com" porque el certificado no validará y el sitio usa HSTS.
En un periódico online como del que se habla aquí lo mismo, un ataque de robo de identidad del sitio podría hacernos pensar que estamos entrando en una web de confianza cuando no, y a partir de ahí usar esa confianza para hacer descargar algo malicioso al usuario, colarle alguna noticia falsa , yo que se, cualquier cosa.
Con respecto a la integridad, hay ataques en donde se intercepta el tráfico y se modifica tipo MitM, si tu te conectas el pais, alguien intercepta la petición o la respuesta y te mete un payload con lo que le de la gana, por ejemplo un javascript con alguna extensión maliciosa (si a alguien le interesa puede mirar por ejemplo http://beefproject.com/ ) pues estas muy jodido, porque con un poco de habilidad pueden usar esa pestaña de navegador para prácticamente cualquier cosa.
En fin, que no es solo el cifrado, son muchas más cosas, hoy en día TODO debería estar cifrado, hasheado y autenticado, no hay excusa de rendimiento que valga.
Esto evita también por ejemplo (es solo un ejemplo eh, pero hay mil) que una extensión maliciosa del navegador pueda llevarte a "su propio google.com" porque el certificado no validará y el sitio usa HSTS.
En un periódico online como del que se habla aquí lo mismo, un ataque de robo de identidad del sitio podría hacernos pensar que estamos entrando en una web de confianza cuando no, y a partir de ahí usar esa confianza para hacer descargar algo malicioso al usuario, colarle alguna noticia falsa , yo que se, cualquier cosa.
Con respecto a la integridad, hay ataques en donde se intercepta el tráfico y se modifica tipo MitM, si tu te conectas el pais, alguien intercepta la petición o la respuesta y te mete un payload con lo que le de la gana, por ejemplo un javascript con alguna extensión maliciosa (si a alguien le interesa puede mirar por ejemplo http://beefproject.com/ ) pues estas muy jodido, porque con un poco de habilidad pueden usar esa pestaña de navegador para prácticamente cualquier cosa.
En fin, que no es solo el cifrado, son muchas más cosas, hoy en día TODO debería estar cifrado, hasheado y autenticado, no hay excusa de rendimiento que valga.
#2:
supongo que es relativamente normal: uno, el cifrado supone una sobrecarga al servidor. Estamos hablando de muchos, muchos, muchos usuarios, por lo que se aplican diversas t'ecnicas para aliviar la carga del servidor. Pequeñas diferencias a pequeña escala en realidad tienen un impacto importante a gran escala. Dos: qué coño les importa el cifrado? no tienen información confidencial, ni páginas privadas para usuarios (que yo sepa). El backoffice estará cifrado, claro. Tres: problema solventable, pero seguramente tendrían problemas cargando unos recursos con HTTP y otros con HTTPS.
#3:
#2 La carga que añade el cifrado era una cuestión importante hace unos años pero hoy en día se considera totalmente despreciable.
Sobre la importancia de cifrar contenido no confidencial, de nuevo: hace unos años no había evidencias tan claras de espionaje masivo, por lo que este tema no estaba en la agenda de empresas como Google.
Sobre la importancia de cifrar contenido no confidencial, de nuevo: hace unos años no había evidencias tan claras de espionaje masivo, por lo que este tema no estaba en la agenda de empresas como Google.
#14:
#13 Ya.. lo peor es que esos mensajes a veces calan y te encuentras a gente totalmente agarrada a unas estadísticas fuera de contexto para no hacer cosas importantes.
Por cierto, y ya como fin (espero) al tema.
El problema del rendimiento tiene soluciones facilísimas:
- Soltar pasta y aumentar proceso/memoria en los servidores, que hoy en día no es nada caro
- Usar servicios escalables en la nube, o montar una nube híbrida para los momentos de carga máxima.
- Usar un CDN que haga el offload de SSL, como cloudflare o si no te fias..
- Usar un proxy inverso propio que solo haga el offload de SSL
Vamos como decía antes, no hay excusa, si la hay es que no se sabe lo que se tiene entre manos.
Por cierto, y ya como fin (espero) al tema.
El problema del rendimiento tiene soluciones facilísimas:
- Soltar pasta y aumentar proceso/memoria en los servidores, que hoy en día no es nada caro
- Usar servicios escalables en la nube, o montar una nube híbrida para los momentos de carga máxima.
- Usar un CDN que haga el offload de SSL, como cloudflare o si no te fias..
- Usar un proxy inverso propio que solo haga el offload de SSL
Vamos como decía antes, no hay excusa, si la hay es que no se sabe lo que se tiene entre manos.
#18:
#14 ahórrate todo eso. Google lo que busca con esa medida es establecer HTTP/2 que es 4 veces más rápido y permite mayor número de conexiones concurrentes en TLS/SPDY que cualquier conexión HTTP 1.1 sin SSL.
Pero el espectáculo de los cuñados explicajndose es como una reserva africana en los documentales.
Pero el espectáculo de los cuñados explicajndose es como una reserva africana en los documentales.
Comentarios
supongo que es relativamente normal: uno, el cifrado supone una sobrecarga al servidor. Estamos hablando de muchos, muchos, muchos usuarios, por lo que se aplican diversas t'ecnicas para aliviar la carga del servidor. Pequeñas diferencias a pequeña escala en realidad tienen un impacto importante a gran escala. Dos: qué coño les importa el cifrado? no tienen información confidencial, ni páginas privadas para usuarios (que yo sepa). El backoffice estará cifrado, claro. Tres: problema solventable, pero seguramente tendrían problemas cargando unos recursos con HTTP y otros con HTTPS.
#2 La carga que añade el cifrado era una cuestión importante hace unos años pero hoy en día se considera totalmente despreciable.
Sobre la importancia de cifrar contenido no confidencial, de nuevo: hace unos años no había evidencias tan claras de espionaje masivo, por lo que este tema no estaba en la agenda de empresas como Google.
#3 No lo sigo muy de cerca pero de nuevo, si no es necesario, y añade ciclos de CPU, no lo hagas. Estamos hablando de muchos usuarios, por lo que impactos que son marginales a pequeña escala pueden suponer más problemas cuando la escala es mucho mayou. Sobre lo de Google espiando el texto que recibes de El País... qué coño me estás contando
#2 #4 Es que estáis pensando en SSL/TLS como un mecanismo únicamente de cifrado y no es sólo eso, también es un mecanismo que garantiza la identidad de los extremos y la integridad del mensaje.
Esto evita también por ejemplo (es solo un ejemplo eh, pero hay mil) que una extensión maliciosa del navegador pueda llevarte a "su propio google.com" porque el certificado no validará y el sitio usa HSTS.
En un periódico online como del que se habla aquí lo mismo, un ataque de robo de identidad del sitio podría hacernos pensar que estamos entrando en una web de confianza cuando no, y a partir de ahí usar esa confianza para hacer descargar algo malicioso al usuario, colarle alguna noticia falsa , yo que se, cualquier cosa.
Con respecto a la integridad, hay ataques en donde se intercepta el tráfico y se modifica tipo MitM, si tu te conectas el pais, alguien intercepta la petición o la respuesta y te mete un payload con lo que le de la gana, por ejemplo un javascript con alguna extensión maliciosa (si a alguien le interesa puede mirar por ejemplo http://beefproject.com/ ) pues estas muy jodido, porque con un poco de habilidad pueden usar esa pestaña de navegador para prácticamente cualquier cosa.
En fin, que no es solo el cifrado, son muchas más cosas, hoy en día TODO debería estar cifrado, hasheado y autenticado, no hay excusa de rendimiento que valga.
#11 Espera, que nos vamos a poner morados de expertos en criptografía cuántica y la "carga de servidor".
#13 Ya.. lo peor es que esos mensajes a veces calan y te encuentras a gente totalmente agarrada a unas estadísticas fuera de contexto para no hacer cosas importantes.
Por cierto, y ya como fin (espero) al tema.
El problema del rendimiento tiene soluciones facilísimas:
- Soltar pasta y aumentar proceso/memoria en los servidores, que hoy en día no es nada caro
- Usar servicios escalables en la nube, o montar una nube híbrida para los momentos de carga máxima.
- Usar un CDN que haga el offload de SSL, como cloudflare o si no te fias..
- Usar un proxy inverso propio que solo haga el offload de SSL
Vamos como decía antes, no hay excusa, si la hay es que no se sabe lo que se tiene entre manos.
#14 ahórrate todo eso. Google lo que busca con esa medida es establecer HTTP/2 que es 4 veces más rápido y permite mayor número de conexiones concurrentes en TLS/SPDY que cualquier conexión HTTP 1.1 sin SSL.
Pero el espectáculo de los cuñados explicajndose es como una reserva africana en los documentales.
#18 Aquí son todos cuñados menos uno mismo...
#18 Bueno claro, ni caía, es que eso es otro tema ya, de hecho no es solo conexiones concurrentes, es que a través de una misma conexión se multiplexan varias peticiones, lo que al final quita carga a todos porque pasa de tener 6 peticiones como ahora a tener solo un socket abierto, todo comprimido, bah que si, que defender lo contrario es un despropósito.
Por cierto sobre eso hice un minicurso en udacity hace muy poco, hecho por google y esta explicado de manera muy simple, con ejemplos muy sencillitos y tal : https://eu.udacity.com/course/client-server-communication--ud897
Igual a alguno le interesa
#26 no porque lo compensas evitando varios handshakes al multiplexar conexiones con http/2, ssl es obligatorio en http/2 de ahí lo que comentabamos en #18 y #22. Al final tienes mucha menos latencia.
#32 Vale, entiendo lo que dices. Pero eso no quita que http/2 sea (o pueda ser) m'as r'apido sin SSL que con. Estoy equivocado?
De nuevo, para qu'e necesita un peri'odico online SSL?
#36 Es que no es que pueda o no pueda, es que es obligatorio, no se puede usar HTTP/2 sin SSL, no hay más, y es infinitamente más rápido.
A ver, resumo las que ya se han dicho y las nuevas, cosas que te pierdes hoy en día si no usas HTTPS:
, derivado de eso:
#28 Cada comentario se me van ocurriendo más cosas
- No cifras, aunque a algunos os importa un.. pero en fin
- Eres vulnerable al espionaje masivo, del ISP, del tio del bar al que te conectas y de quien le de la gana
- Cualquier proxy puede recopilar estadísticas no solo de los sitios que visitas, si no del contenido concreto que te interesa
- No puedes verificar Identidad (Ataques de envenenamiento DNS, robo de identidad, secuestro de servidores, MitM, etc)
- No puedes comprobar la integridad (Los ataques de arriba básicamente pero con inyección de payloads)
- No puedes usar HTTP/2
- No puedes hacer PWAs, que con la cantidad de móviles que acceden a una web hoy en día es un suicidio, porque no puedes controlar cómo carga la app en determinadas condiciones, por ejemplo cuando no hay cobertura, o como se controla la caché, o si se puede añadir como app, etc
#37 Vale, peque;o detalle que se me ha pasado, que HTTP/2 implica usar SSL. Ando un poco desconectado del tema, por si no se nota jaja. Gracias
#40 No lo implica en el sentido de que el estándar no lo hace obligatorio. Pero sí es cierto que la mayoría de navegadores no aceptan comunicaciones http/2 sin cifrar.
#37 Muchos de esos puntos afectan al servidor que da el servicio, pero no a mí como usuario. ¿Qué espionaje masivo van a hacerme al visitar un periódico donde sólo voy a leer? ¿Van a espiar el contenido que me interesa? Pero si eso ya lo ven en la url...
Otro tema es usar https en webs donde el usuario tiene un comportamiento más interactivo, pero en un periódico, el usuario es bastante pasivo. Simplemente es receptor de información.
#43 es que estas equivocado, la url no se ve en la petición cifrada, solo el servidor
#44 En ese caso, me retracto.
#49 Sinceramente, eso es lo que menos me podr'ia preocupar. Que no me parece bien que google pueda usar eso para meter las narices, pero teniendo en cuenta lo que se hace con cookies y que la mayor'ia de webs usa ga... meh.
#37 Pues igual meto mano a par de servidores y sitios que tenemos para que usen HTTP/2 (o muevo que se haga, jeje). Cualquier mejora de rendimiento y potencialmente de SEO es bienvenida.
Gracias.
#52 Si quieres experimentar, mi recomendación es usar cloudflare, con el plan gratuito ya te hacen de CDN, te implementan ellos HTTPS, HTTP/2 y te optimizan la carga de recursos estáticos. La única pega es que se ponen en medio, pero hoy en día jugar a evitar esas cosas es un poco casi imposible.
#53 Bueno, pues vamos a experimentar con varios dominios que tenemos en un servidor de produccio'n. No es que tengamos miles de visitas al d'ia, pero algunas visitas hay. Vamos a experimentar en caliente jaja.
Ni de co;a vamos a cambiar de hosting ahora. Si hay algo de lo que deber'ia de estar al tanto dime ahora o ya te cuento luego lo que casc'o
#18 Genial, dos personas debatiendo sobre motivos técnicos para usar o no SSL en los servicios web y tú "contribuyes" con una opinión personal (que podría incluir
) sobre los motivos de Google para presionar en el uso de SSL.
- En el futuro los "Cuñados" llamarán al resto "cuñados" (Un Cuñado, 2018) -
#11
soy experto en criptografia y no podrá haberlo explicado mejor, me quito el sombrero, imagino que tu también en la industria (ingeniero de algún tipo)
#13
aprovecho lo que comentas para agregar algo mas de información al asunto.
La computación cuántica podría usar el algoritmo de shor para factorizar enteros muy rápido, tan rápido, que se vuelve viable factorizar la cantidad de números necesarios para atacar ECDSA, RSA, etc.
Sin embargo, esto tiene algunas consideraciones:
- La computación cuántica está lejos de poder ejecutar el algoritmo de shor a la escala necesaria para atacar ECDSA y similares. Si bien teoricamente se podría, aun no hemos llegado ahí, y faltan años para que eso pase (incluso si suponemos que la computación cuántica va a vivir un desarrollo exponencial).
- Aunque mañana se pudiese ejecutar el algoritmo de shor a la escala necesaria para romper ECDSA o RSA, tu comunicación de hoy hubiese sido mucho mas segura que sin cifrar. Basicamente por que si bien podrán mañana encontrar el número primo necesario para leer todo lo que te envío y recibistes de meneame, como mínimo sabes con seguridad que hoy, meneame.net es quien dice ser, que nadie lo ha suplantado en la comunicación
- Cuando la computación cuántica avance lo suficiente para amenazar a ECDSA en el corto plazo, cambiaremos los certificados y empezaremos a usar algoritmos resistentes a la computación cuántica, como merkle signatures o rainbow signatures, o cualquier otra cosa que exista en ese momento
Es decir, hoy la computación cuántica no puede atacar ECDSA y faltan años para que pueda hacerlo, antes de que pueda hacerlo ya habremos cambiado de algoritmo y cuando lo consiga y rompa ECDSA, entonces podrá leer los mensajes cifrados de aquel momento, si es que ha guardado toda la conversación hasta la fecha, pero eso no le permite viajar al pasado e impersonar al servidor en la comunicación que tuvo contigo
#11 Pero es que de nuevo, es de los sitios web que menos importa proteger con HTTPS. Y ya s'e que el tema no s'olo es confidencialidad sino tambi'en autenticaci'on.
Respecto a los comentarios de hace 8 a;os, el handshake ya no introduce latencia como hace 8 a;os?
#26 Arregla el teclado o escribe sin tildes. Pero así no hay quien lea tus comentarios.
#48 no me llorencs tanto.
#4 a google no le interesa saber que texto de El Pais estas leyendo. A google le interesa saber que estas leyendo el pais, y sobre todo, la URL a la que estas accediendo para: 1) meterte publicidad segun la URL y 2) categorizarte como usuario para vender un paquete de usuarios categorizados a quien se lo quiera comprar.
con sitios cifrados por HTTPS, se puede saber que estas conectandote a 'El Pais' (cosa que ya de por si es bastante mala), pero no pueden saber que URL exacta estas accediendo.
con HTTP plano, practicamente te estas bajando los pantalones mientras cantas 'esta sera su casa, para lo que quiera y mas...'
#3 Mira lo que dicen ac'a:
https://stackoverflow.com/questions/149274/http-vs-https-performance
Si tienes muchas visitas cortas (que a d'ia de hoy ser'ia posiblemente lo que pasa teniendo tantos enlaces entrantes), la carga y la latencia que añaden el cifrado (y el handshake) sí tiene relevancia. Y de nuevo, estamos hablando de webs en las que se intenta minimizar la carga del servidor de varias maneras, porque realmente es fácil que haya picos que te tiren el servidor abajo. No es un blog o una aplicación web para una empresa. Curioso que te hayan dado un positivo
#5 https://security.googleblog.com/2014/08/https-as-ranking-signal_6.html?showComment=1407569840779#c1503709338745200400
#5 Te has quedado en los mensajes escritos hace ocho años.
To sum it up, let me quote Ilya Grigorik: "TLS has exactly one performance problem: it is not used widely enough. Everything else can be optimized."
#5 Una consulta de hace 5 años, anda que no han cambiado las cosas desde entonces.
Por ejemplo, las páginas de mi sitio web que aquel año no usaba https solían cargar en 0.5 segundos. Hoy en día usa https y con el mismo coste de servidor cargan en menos de 0.3 según alexa (adjunto imagen)
#30 Hombre, eso puede ser por la carga y la configuraci'on de la red en s'i misma. No?
#33 o simplemente que la carga del encriptado es insignificante respecto a otros aspectos como las consultas a la base de datos o la gestión de sesiones.
Entre el rastreo de motores de búsqueda y los usuarios, mi web tiene aproximadamente 3 solicitudes por segundo (Ten en cuenta que Alexa solo te muestra la velocidad de la web si superas los 20.000 usuarios al día). Hay picos que puede llegar a 20 solicitudes por segundo. Pago por un servidor dedicado menos de 30€ al mes y rara vez supera el 20% de ocupación de la CPU estando todo - Bases de Datos (usa dos instancias), Servidor de Aplicaciones y Proxy nginx - en la misma máquina.
#3 te preocupa el espionaje masivo mientras usas Chrome.
Que te van a espiar cuando entras en elmundo? En todo caso querran recopilar telemetria para meterte publicidad, saber en que noticias entras, en que periodico entras, para saber lo que te interesa y google analitics y el boton de facebook que se encargan de eso funcionan sin problemas con https.
#7 Usa uMatrix y abur Google Analitics y botones de redes sociales.
#7 efectivamente. De lo que más te protege el https es de que alguien pueda capturar tu actividad desde dentro de tu propia red.
Y por cierto, a Google le interesa el https por esta razón. Sin https , los proveedores se pueden dedicar a recopilar datos de navegación con fines comerciales, y eso para Google es competencia. A ver si os creéis que lo fomentan porque os quieren mucho.
#3 pregunto, q no se:
Y q pasa con las caches? No se cachea nada?
#2 El coste de la carga que supone el cifrado en un servicio online del tamaño y tráfico de los que se citan en la noticia no es relevante.
La de máquinas que levantará marca.com cuando suceda un evento relevante, y más ahora que todos los sistemas escalan automáticamente, hace que el coste de encriptado sea despreciable para el negocio.
Ha sido desidia, sin más.
#2 hay mucha prensa en la que te tienes que registrar para poder comentar o ver contenido premium.
#2 Eso es porque las webs no cifradas que ya son de por sí inseguras, y que tienen brechas de seguridad, nunca han sido multadas convenientemente. Ya veremos ahora con el RGPD y el nuevo reglamento de e-Privacidad que está en su etapa final de aprobación (el primero ya está en vigor) lo que pasa cuando vuelva a haber algo similar a Cambridge Analytica o peor, robo de datos. Y por cierto muchos periódicos que no usa sistemas como Disqus, y tienen comentarios propios si guardan información de sus usuarios/as.
Salu2
#59 Guardar informaci'on de sus usuarios no tiene nada que ver usar http o https. Otra cosa es cuando se env'ia esa informaci'on. Pero guardar... lo mismo con Cambridge Analytica. Nada que ver con https.
#61 No hablé de https. De hecho una página puede tener https, si vincula a un servidor no cifrado esa página será insegura, si almacena o guarda datos sin estar cifrados esa página es insegura igualmente.
Salu2
curioso que barrapunto sea una de ellas (de las que no usan cifrado)
#15 Barrapunto no usa cifrado y, cuando lo usa, lo usa mal. Aunque no es curioso teniendo en cuenta que Barrapunto lleva comatoso desde hace años .
#56 Hombre.. justo los certificados de letsencrypt no puedes decir que sean complicados de instalar, concretamente con certbot es una linea..
https://certbot.eff.org/lets-encrypt/ubuntuxenial-apache
ejemplo
#57 Estuve mirando un poco y el proceso me parecía complejo. Encontré una utilidad para IIS en lo generaba en segundos.
Pero como no vi más entendí que para otros sistemas, o para gente que lo hiciera por sí misma, podría ser un engorro.
Existiendo como existe Let's Encrypt no tiene mucha explicación la falta de cifrado.
De hecho siendo como es algo de interés general el propio Estado debería ofrecer servicios de generación de certificados para sitios web. Pero náááááá, esto tiene que salir de los de abajo como ya ha ocurrido con el DNIe.
Es que no necesito para nada que un periódico tenga protocolo https, salvo en la página de pago (que puede estar perfectamente implementado en una pasarela). Que puede ser positivo que encripte mis comentarios durante el envío, pero aparte de eso, no hay nada especial que requiera cifrado.
Tienes certificados por veinte euros al año. Y aunque fuera necesario comprar uno carísimo hablamos de un coste de mil euros anuales para empresas que facturan varios millones.
El coste del cifrado solo tienesentido en páginas webs "caseras".
Por cierto, elpais.es sí que está cifrado pero la noticia dice que no.
#16 tienes certificados gratis con letsencrypt, así que ni para webs caseras es excusa
#24 Pero pueden ser un coñazo de instalar por primera vez.
Una empresa, claro, una web que haces algo más chorra... Pues no me compensa el tiempo de "investigación"
#16 además de que es elpais.COM
Noticia errónea
Chrome cabrones. 👆
🔴 💥 💣
Sólo queda una versión para el exterminio de las páginas http
artículo erróneo. Elpais hace más de un año que cifra todo
Uhhh si, es super necesario el cifrado en páginas de acceso abierto donde la información es unidireccional.
Espero que no venga un jaker y me cuele una noticia cierta
Antes de que se dispersen, que alguien anille a todos los nuevos ejpertos en mod_ssl, para averiguar si son migratorios o si se mueven en bandadas.
Ya están balanceando el Ftp con la telemetría otra vez. Anda que...
#8 Es que el tema est'a en el tipo de sitios web de los que se est'a hablando. No se trata tanto de ser un experto en un m'odulo de Apache. Ahora que t'u suenas o quieres sonar como un experto... igual podr'ias iluminarnos a los dem'as un poco.
#10 No tenéis ni idea de lo que habláis.
#12 tu opini'on ahora mismo vale menos que la mierda que dejo en el vater.
#8 mod_ssl, madre mía, que estamos, en los 90?
Yo no se como ha hecho las pruebas pero llevo años entrando a El Pais por https en exclusiva.
#41 Sí, ya está corregido
Y algún ministerio...