Nuevo capítulo de la interminable guerra del navegador Google Chrome contra las páginas webs no seguras que no utilizan HTTPS por defecto. A partir de la llegada de la nueva versión, que llegará a lo largo del día de hoy bajo el nombre Google Chrome 68, todas las webs sin HTTPS serán marcadas como no seguras.
#19:
#17 Let's Encrypt... Te permite gererar certificados en segundos, y que se renuevan automáticamente. El coste ya no es una excusa. https://letsencrypt.org/
#11:
#8 el cifrado en todas las paginas es innecesario, ¿Para que quieres cifrado en una web de contenido irrelevante que ni contraseñas maneja? La medida es exagerada.
#13:
#11 Te aseguras de que tu conexión con el servidor es privada y que no puede ser modificada al vuelo por un ataque Man-in-the-middle.
#91:
La seguridad es necesaria, y por norma general se deben securizar los canales. Pero veo absurdo que un navegador obligue a usar https, como muchos indican es innecesario en segun que contenidos. Si quieres mostrar un texto plano público sin java, sin base de datos y que no requiere securizar el canal, para que obligarte a usar https?
Los "candados" son importantes para la información importante, pero imaginan que obligasen a poner candados a un cartel de "Alquilo plaza de garaje".. es absurdo si te sobra con atarlo con una brida.
Si alguien sabe un poquito de seguridad y se ha leido los RFC, podrá comprobar que hasta en servicios de PKI (TSA, OCSP y CRL) que son infraestructuras donde se exige los mas estrictos niveles de seguridad, en OCSP por ejemplo no se exige la obligatoriedad de https, quizás con el tiempo se obligue. Pero que lo exija el navegador...
#62:
Una medida más para alejar la web del usuario particular y convertirla cada vez más en coto de las grandes empresas.
Varias de mis webs favoritas son páginas personales de gente que colgó en un servidor unos cuantos ficheros de HTML estático. Ni Javascript, ni leches. Por supuesto, no piden registro, ni contraseña, ni datos de ningún tipo. No tienen nada de "no seguras". Con esto se cargarán ese tipo de páginas porque, aunque se pueden obtener certificados gratis, eso requiere (1) bastantes más conocimientos técnicos y esfuerzo que subir un HTML estático, y (2) actualizarlo periódicamente.
Por otra parte, ya me he comido leaks de contraseñas de varios servicios de grandes empresas, por supuesto bajo riguroso HTTPS.
Ni un pelo me gustan estas cosas que hace Google (ya no es la primera, también se cargó los applets Java que tuvieron sus problemas de seguridad, pero no más que otras tecnologías que hay por ahí). Seré raro pero prefiero que sean los internautas, y no una gran empresa, los que decidan qué contenidos sobreviven en la red y cuáles mueren o son ignorados.
#55:
El cinismo de Google con estas estupideces es supremo, sobre todo sabiendo que Chrome envia a Google todas las páginas que visitas. Google va a velar por tu privacidad y seguridad, siempre que pueda seguir sacando toneladas de datos para encajarte publicidad hasta en la sopa...
#68:
#16 no entiendo por qué pasar de http a https jode una plantilla. Por el concepto"plantilla" en sí mismo, entiendo que tienes un CMS o una tienda online.
Supongo que tu web funciona (como todas) con un servidor (al que puedes instalar Let's Encrypt por ejemplo), una "carpeta" de archivos (donde tendrás un CMS o los html o PHPs o la tecnología que uses, que aquí como mucho tendrás que tocar en código cuál es la nueva URL del sitio, cambiando http por https) y una base de datos (donde reemplazar todas las llamadas http por https con un margen de error bajísimo)... es decir, ¿por qué tu plantilla se jode por tocar en el server, en la base de datos y a lo sumo en un par de líneas de código de la propia web?
Por otro lado, si lo de que se te jode la plantilla te lo ha dicho tu proveedor de hosting, cambia de proveedor. Si como sospecho, tienes un WordPress, el combo completo se hace en 15' con un margen de error en imágenes (que siguen siendo llamadas por http en lugar de https) de menos del 5%. Con esas toca machacarlas a mano... aunque yo, de todas las migraciones que he hecho en un año, no he tenido ni un solo problema con imágenes. Al hacer el reemplazo en base de datos todo ha pasado a "llamarse" por https.
Amplía información por favor
#17:
#13 me parece bien la medida si el certificado lo emite Google gratis. Por cada web con SSL hay una pasta en cerrificados y un pedazo de negocio detrás y no, no vale autofirmarse el cerrificado, el servidor detecta que no es una entidad cerrificadora valida.
PS: creo que la FSF liberó una herramienta para certificarse gratuitamente, pero no se si lo añade en el contenedor de ceritficados el navegador.
#10:
Es de chiste pasarse por las webs de la administración del Estado y ver que casi ninguna es segura.
#21:
#17 y que hay de las webs antiguas o que no puedan adaptarse? No. Es exagerado totalmente.
#23:
Botnets infectando millones de routers en el mundo y todavía lees aquí que el HTTPS es innecesario. Qué poco valoráis la integridad del código que se ejecuta en tu máquina...
#26:
#11 Para no desvelar tus comunicaciones ante terceras partes y asegurar que no inyectan código malicioso. Puede que para una web concreta no lo necesites pero, desde el punto de vista de cyberseguridad, es importante no revelar qué comunicaciones son seguras/importantes y cuáles no.
#15:
Venga, a tirarme una mañana perdiendo el tiempo para ver cómo pasar mi puto portfolio en Wordpress a https. Gracias Google.
#20:
#15 Si para ti añadir seguridad es perder el tiempo, por favor, dediquese a otra cosa y deje a los profesionales trabajar. De nada por el consejo.
#18:
En ciertas webs lo entiendo, pero en otras es ridículo.
#17 Let's Encrypt... Te permite gererar certificados en segundos, y que se renuevan automáticamente. El coste ya no es una excusa. https://letsencrypt.org/
#8 el cifrado en todas las paginas es innecesario, ¿Para que quieres cifrado en una web de contenido irrelevante que ni contraseñas maneja? La medida es exagerada.
#13 me parece bien la medida si el certificado lo emite Google gratis. Por cada web con SSL hay una pasta en cerrificados y un pedazo de negocio detrás y no, no vale autofirmarse el cerrificado, el servidor detecta que no es una entidad cerrificadora valida.
PS: creo que la FSF liberó una herramienta para certificarse gratuitamente, pero no se si lo añade en el contenedor de ceritficados el navegador.
El cinismo de Google con estas estupideces es supremo, sobre todo sabiendo que Chrome envia a Google todas las páginas que visitas. Google va a velar por tu privacidad y seguridad, siempre que pueda seguir sacando toneladas de datos para encajarte publicidad hasta en la sopa...
Una medida más para alejar la web del usuario particular y convertirla cada vez más en coto de las grandes empresas.
Varias de mis webs favoritas son páginas personales de gente que colgó en un servidor unos cuantos ficheros de HTML estático. Ni Javascript, ni leches. Por supuesto, no piden registro, ni contraseña, ni datos de ningún tipo. No tienen nada de "no seguras". Con esto se cargarán ese tipo de páginas porque, aunque se pueden obtener certificados gratis, eso requiere (1) bastantes más conocimientos técnicos y esfuerzo que subir un HTML estático, y (2) actualizarlo periódicamente.
Por otra parte, ya me he comido leaks de contraseñas de varios servicios de grandes empresas, por supuesto bajo riguroso HTTPS.
Ni un pelo me gustan estas cosas que hace Google (ya no es la primera, también se cargó los applets Java que tuvieron sus problemas de seguridad, pero no más que otras tecnologías que hay por ahí). Seré raro pero prefiero que sean los internautas, y no una gran empresa, los que decidan qué contenidos sobreviven en la red y cuáles mueren o son ignorados.
Botnets infectando millones de routers en el mundo y todavía lees aquí que el HTTPS es innecesario. Qué poco valoráis la integridad del código que se ejecuta en tu máquina...
#11 Para no desvelar tus comunicaciones ante terceras partes y asegurar que no inyectan código malicioso. Puede que para una web concreta no lo necesites pero, desde el punto de vista de cyberseguridad, es importante no revelar qué comunicaciones son seguras/importantes y cuáles no.
Por no decir que estar mostrando el aviso de marras, y darle al botón de excepción siempre por costumbre y sin mirar, se va a hacer ahora mucho más, y eso sí que es inseguro
La seguridad es necesaria, y por norma general se deben securizar los canales. Pero veo absurdo que un navegador obligue a usar https, como muchos indican es innecesario en segun que contenidos. Si quieres mostrar un texto plano público sin java, sin base de datos y que no requiere securizar el canal, para que obligarte a usar https?
Los "candados" son importantes para la información importante, pero imaginan que obligasen a poner candados a un cartel de "Alquilo plaza de garaje".. es absurdo si te sobra con atarlo con una brida.
Si alguien sabe un poquito de seguridad y se ha leido los RFC, podrá comprobar que hasta en servicios de PKI (TSA, OCSP y CRL) que son infraestructuras donde se exige los mas estrictos niveles de seguridad, en OCSP por ejemplo no se exige la obligatoriedad de https, quizás con el tiempo se obligue. Pero que lo exija el navegador...
#16 no entiendo por qué pasar de http a https jode una plantilla. Por el concepto"plantilla" en sí mismo, entiendo que tienes un CMS o una tienda online.
Supongo que tu web funciona (como todas) con un servidor (al que puedes instalar Let's Encrypt por ejemplo), una "carpeta" de archivos (donde tendrás un CMS o los html o PHPs o la tecnología que uses, que aquí como mucho tendrás que tocar en código cuál es la nueva URL del sitio, cambiando http por https) y una base de datos (donde reemplazar todas las llamadas http por https con un margen de error bajísimo)... es decir, ¿por qué tu plantilla se jode por tocar en el server, en la base de datos y a lo sumo en un par de líneas de código de la propia web?
Por otro lado, si lo de que se te jode la plantilla te lo ha dicho tu proveedor de hosting, cambia de proveedor. Si como sospecho, tienes un WordPress, el combo completo se hace en 15' con un margen de error en imágenes (que siguen siendo llamadas por http en lugar de https) de menos del 5%. Con esas toca machacarlas a mano... aunque yo, de todas las migraciones que he hecho en un año, no he tenido ni un solo problema con imágenes. Al hacer el reemplazo en base de datos todo ha pasado a "llamarse" por https.
Amplía información por favor
#75 hombre es que ofrecerlo tiene un coste en el rendimiento del sistema que en el caso de miles o millones de conexiones no es nada despreciable. y por desgracia nadie regala CPUs ni electricidad
#87 vale, tu tienes 27 visitas por segundo y no tiene apenas impacto pero nosotros tenemos mas de 15000 conexiones simultaneas y hemos tardado años en poder soportar SSL. y una empresa de hosting puede tener muchas mas
#126 utilizamos balanceadores de carga y granjas de servidores para distribuir la carga de los 15000 clientes conectados de forma simultanea, pero seguro que es comparable con un servidor con 27 conexiones simultaneas y nuestro departamento de redes y sistemas esta equivocado. porque activar el SSL no implica ningun gasto de recursos que lo has comprobado tu en tu servidor apache ejecutando el comando free. paso de perder el tiempo..
#131 ya te he dicho que estamos todos equivocados, y no usamos SSL porque somos demasiado tontos como para leer un pdf y mucho menos lidiar con la complejidad de configurar un servidor con nginx.. vamos que es un milagro que no nos clavemos el tenedor en la cara al comer
#55 Y sobretodo un detalle, una web en la que no te logeas para nada, ni compras nada, simplemente ves contenido, no se para que cojones necesita https.
#21 el cetiificado lo maneja el servidor (apache, nginx, iis...) Si la web está medianamente bien hecha debe funcionar con https sin problemas. El mayor problema seria que los enlances internos redirigieran de vuelta a http.
#19#17 lo uso desde hace un año en mi server y es gloria bendita. Tengo muchos clientes que llegan preocupados por el tema de https sobre todo por posicionamiento pero para según que wes, que no guardan contraseñas, me parece excesivo pagar un certificado. Con esto tengo todas mis webs en https (incluso las que no estaban antes, aunque eso tiene un poco más de tareilla)
#13 el Https pueden ser hackeado por un Man-in-the-middle. Precisamente el Man-in-the-middle es para eso. No puede ser hackeado con ataques más sencillos que si funcionan en no Https.
Does HTTPS prevent Man In The Middle attacks?
Posted on October 8, 2015 by eric
A common belief is that the HTTPS protocol prevents so-called Man In The Middle (MiTM) attacks. Unfortunately, in some circumstances, this assumption is wrong.
Ya esto me genera problemas con Chrome porque muchas configuraciones muchos controles de muchos equipos técnicos lo hago en plataforma web y cada vez que entro por primera vez me dice que un sitio inseguro blablablablabla
No sé si habrá una forma de saltarse porque la verdad estoy cansado
#24 https no es 100% efectivo, pero casi. Es prácticamente imposible romper el certificado, la única forma es engañar al navegador para que acepte un certificado no válido, que es lo que explica tu enlace.
No tiene sentido comparar algo tan rebuscado con el “todo abierto” de http, donde es imposible detectar ninguna modificación del contenido ya que no hay ningún tipo de cifrado.
#73 o tiene una pagina web que ha hecho el para sus mierdas o su curro (que intrusismo es ese). Y como no le gusta la programacion de paginas web. Como a ti. Pues le da pereza. De los peores troles de la historia. En serio. Tú.
#20 vaya, vaya, así que complicar las cosas para que usuario de a pie no pueda hacer las cosas y tenga que recurrir a "profesionales". Claro como las bombillas de los coches, las baterías de los móviles, y todas esas cosas que antes podía apañar uno mismo y ahora no.
Curioso nick el tuyo.
#6 21 dic. 2016. La encriptación SSL será obligatoria a partir de 2017. Como venimos comentando últimamente en nuestras noticias, nos vemos en la obligación de recordar que la encriptación SSL ya no es algo opcional, es algo obligatorio. Dependiendo del tipo de sitio web, durante el año 2017 los navegadores penalizarán aquellos que no dispongan de encriptación SSL. https://www.redalia.es/noticia/la-encriptacionssl-sera-obligatoria-a-partir-de2017-0018/
#16 solo tienes que cambiar los enlaces internos a URL absoluta sin incluir el dominio. Si redireccionas a https mwdiante htaccess (por ejemplo) perderias los datos en todas las peticiones POST
#11 No hace falta que la web tenga formularios, sin https, mediante un ataque MitM, como dice #13, te pueden inyectar malware, sustituyendo cualquier script de la página por uno infectado, por ejemplo jQuery. Y con esto y aprovechando otros fallos de seguridad (Saltándose el sandbox del navegador, difícil pero no imposible) te pueden hacer un traje en el PC, por ejemplo robándote contraseñas, instalando minadores, adware, etc.
#16 yo he pasado 3 o 4 webs de http a https en lo que va de año, todas de su padre y de su madre, ninguna mia hecha de 0. Y no es para nada complicado. Como ya te han dicho, como mucho hay que cambiar http por https si tienes enlaces absolutos (Buscar y reemplazar, y añadir la S). Si usas enlaces relativos no hay que hacer absolutamente nada, tan solo cambiar la configuración del servidor. Si tienes reescritura de URLs te tocará modificar la configuración del servidor o del sitio, en el fichero .htaccess en el caso de Apache, o donde corresponda.
Tarde o temprano te va a tocar pasar por el aro, así que cuanto antes empieces mejor.
#11#66 por eso precisamente se trata de evitar un man in the middle con el https
Porque en teoría el de la web “normal” que no quiere Joder a nadie no hace eso, y si por https lo evitas, evitas que hagan lo que dice #66
En resumen, que se pongan de teléfono roto entre medio del servidor de la página y tú, y cambien algunos mensajes sin que te enteres, para infectarte (resumen a pie de calle)
#65 El path de la página va cifrado, pero el dominio no. Pueden saber perféctamente que estás visitando www.meneame.net y por cuanto tiempo, aunque no puedan ver las URL completas.
#79#89 la clave la está dando #67 respecto a esas redirecciones a https mediante 301: son redirecciones que provocan la perdida de los datos post (por qué tendrían que enviarse bajo https)
Esto por ejemplo en un caso particular mío es un problema importante: webservice con unos 250 clientes integrados apuntando a una dirección sin http, con unas 20-30 conexiones por segundo al endpoint y funcionamiento 24x7.
Primero, que meterle mano a ese código (ya muy antiguo) es un problema de base puesto que efectivamente se montan enlaces con http "hardcoded".
Segundo, y más importante, los clientes que se integraron hace años se ven obligados a hacer un cambio de su lado lo cual puede llevar tiempo.
#98 hombre, inmune a todo tampoco, https en su versión más básica, "solo" te asegura que el dominio de destino y el servidor que sirve el certificado coinciden y que la comunicación con este servidor va cifrada.
A partir de ahí pueden existir otros muchos problemas en los que el SSL no tiene nada que ver.
#11 Sirve para evitar que otros conozcan qué paǵinas visitas, además, en las páginas en las que se pueden dejar comentarios, para conservar tu anonimato.
#83 No se si lo dices de coña pero el hecho de servir páginas en SSL tiene un coste de CPU mínimo. Ahora mismo tengo un apache sirviendo 27 pag/sec de media con una carga cpu 2.20 y el balanceador nginx por delante que está haciendo todo el paso de http a https apenas tiene 0.08.
#37 Downgrandear una conexión https se soluciona con el HSTS, como dice en el artículo que mentas. Y desde 2016 ha llovido mucho. No me puedo creer que hables de carga del servidor cuando cifrar una conexión no es nada comparado con la latencia de leer del disco duro. La CPU está para usarse y si tienes que contratar algo más potente, se contrata. Miedo me da que haya gente que piense que el https es una medida exagerada
#98 no discutas, estos te están diciendo que vacunarse no está guay porque aún así, puede coger la enfermedad (se han dado casos) y por tanto, dado que hay un 0,000000001% de posibilidades de fallo, para que vacunarse?
#32 no recuerdo ninguna infeccion de ese tipo aprovechandose de un MITM pero si recuerdo unas cuantas aprovechandose de los anuncios y eso se puede hacer con https igual que sin el.
Pero bueno, podria ser un vector menos, el dia que el 95% de las webs implementen correctamente https y no como ocurre en el enlace que puse.
El problema es que https añade carga extra al servidor y en peticiones pequeñas pero abundantes, algo se nota.
#34 En Plesk hay una opción en la configuración de dominio para que todas las peticiones con protocolo http sean convertidas automáticamente a https, así que sin problemas: Sitios web y dominios -> Configuración de hosting -> Redireccionamiento 301 permanente de HTTP a HTTPS preservando SEO
Una vez más, Google sujeta la bombilla y el resto damos vueltas a la casa.
¿Desde cuándo una empresa privada y ajena nos dice qué protocolos tenemos que usar? ¿Es que acaso trabajamos para ellos?
#102 Lo de que Google, Facebook & co te puedan seguir rastreando con sus beacons lo obviamos, ¿no? Y que el mayor suministrador de certificados de bajo o nulo coste sea la gran G, tambien
#107 Tu hablas de lo técnico, yo de la parte de usuario y falsas sensaciones. Que una conexión esté tunelizada no quita para que lo que pase a través de ella sirva para rastrearte, o que un tercero que lo está haciendo tenga las llaves de todo el chiringuito
#8 pensaba eso desde que lo supe y lo sigo pensando. No puedo pasar a http sin cargarme la plantilla que tengo ahora. Seguramente seguirá el descenso de usuarios por culpa de esto que es totalmente innecesario.
#34: ¿Y si colgaste una página web y no tienes ganas de andar enredando?
Más que nada, porque no ganas dinero con ello, tampoco obtienes reconocimiento, y no vas a estar trabajando gratis porque a Google o a otros expertillos les venga bien.
Y respecto al coste, en la página web pone esto: "Donate". ¿Qué pasará el día en que no haya suficientes donaciones? Además, es forzar a la gente a depender de terceros.
¿Alguien ha calculado el coste medioambiental de esta medida? Lo digo en serio. Además del coste implícito que tiene sobre la libertad y neutralidad de la red. Un gigante tecnológico tratando de imponer su criterio a la fuerza (tenga o no razón). Si fuera Microsoft ya estaríais quemando fotos del amigo Bill.
#17 ya te puedes certificar gratis con letscript y google es patrocinador. No estar certificado es para una web decente, pereza. Para la web de «tu primo» igual es falta de conocimiento (solventable).
#30 Ah... Pero hay montones de metadatos (e información de cuentas ya de usuario) que se transmiten pero no se publican. Y también es verdad que muchos sistemas de seguimiento (no necesariamente cookies) quieren estar seguros de que tú eres quien dices ser.
#85 No lo asegura pero lo hace muchísimo más complejo. Necesitas manipular la cadena de confianza del navegador para que este se coma con patatas un MitM y para eso necesitas acceso al host atacado.
Una conexión http es siempre una conexión no segura. Ahora bien una web con https no significa que sea segura. Primero si se hace la idiotez de mezclar contenido mixto http y https, por otro lado si se usan algoritmos o protocolos no seguros. Por eso hay webs que algunos navegadores aún con https las marcan como inseguras. También si un certificado es falso o está caducado, claro.
Entonces tenemos que el https evitará un MITM para que no te puedan inyectar malware, que representa un ¿5%? de los casos reales, pero seguiremos teniendo otras técnicas como el malvertising que se están usando en el ¿95%? restante. ¿Es así? Si es así, poco (nada) va a solucionar el https.
#133 Me he perdido con tanta metáfora y no he entendido nada.
En cuanto a tu última frase, ¿por qué dices que "llegar a ese tipo de ingeniería de software para crear un virus, no es tan fácil.... "? si lo más fácil es justamente el malvertising y eso no se soluciona con https.
#143 Sí, te garantiza que el html que recibes sea auténtico pero al malvertising le da igual porque el malvertising no cambia para nada el html original, no lo necesita, ya sea a través de simple http o https.
Comentarios
#17 Let's Encrypt... Te permite gererar certificados en segundos, y que se renuevan automáticamente. El coste ya no es una excusa. https://letsencrypt.org/
#8 el cifrado en todas las paginas es innecesario, ¿Para que quieres cifrado en una web de contenido irrelevante que ni contraseñas maneja? La medida es exagerada.
#11 Te aseguras de que tu conexión con el servidor es privada y que no puede ser modificada al vuelo por un ataque Man-in-the-middle.
no uso Chrome, gracias
Es de chiste pasarse por las webs de la administración del Estado y ver que casi ninguna es segura.
#17 y que hay de las webs antiguas o que no puedan adaptarse? No. Es exagerado totalmente.
#13 me parece bien la medida si el certificado lo emite Google gratis. Por cada web con SSL hay una pasta en cerrificados y un pedazo de negocio detrás y no, no vale autofirmarse el cerrificado, el servidor detecta que no es una entidad cerrificadora valida.
PS: creo que la FSF liberó una herramienta para certificarse gratuitamente, pero no se si lo añade en el contenedor de ceritficados el navegador.
El cinismo de Google con estas estupideces es supremo, sobre todo sabiendo que Chrome envia a Google todas las páginas que visitas. Google va a velar por tu privacidad y seguridad, siempre que pueda seguir sacando toneladas de datos para encajarte publicidad hasta en la sopa...
Venga, a tirarme una mañana perdiendo el tiempo para ver cómo pasar mi puto portfolio en Wordpress a https. Gracias Google.
Una medida más para alejar la web del usuario particular y convertirla cada vez más en coto de las grandes empresas.
Varias de mis webs favoritas son páginas personales de gente que colgó en un servidor unos cuantos ficheros de HTML estático. Ni Javascript, ni leches. Por supuesto, no piden registro, ni contraseña, ni datos de ningún tipo. No tienen nada de "no seguras". Con esto se cargarán ese tipo de páginas porque, aunque se pueden obtener certificados gratis, eso requiere (1) bastantes más conocimientos técnicos y esfuerzo que subir un HTML estático, y (2) actualizarlo periódicamente.
Por otra parte, ya me he comido leaks de contraseñas de varios servicios de grandes empresas, por supuesto bajo riguroso HTTPS.
Ni un pelo me gustan estas cosas que hace Google (ya no es la primera, también se cargó los applets Java que tuvieron sus problemas de seguridad, pero no más que otras tecnologías que hay por ahí). Seré raro pero prefiero que sean los internautas, y no una gran empresa, los que decidan qué contenidos sobreviven en la red y cuáles mueren o son ignorados.
En ciertas webs lo entiendo, pero en otras es ridículo.
Botnets infectando millones de routers en el mundo y todavía lees aquí que el HTTPS es innecesario. Qué poco valoráis la integridad del código que se ejecuta en tu máquina...
¿Eso afecta a las páginas porno? Lo digo porque estoy empezando a agobiar e, hay un amigo que me lo está preguntando y no se que responder
#1 Si viaja por HTTP es porno no seguro; si no, porno seguro.
#15 Si para ti añadir seguridad es perder el tiempo, por favor, dediquese a otra cosa y deje a los profesionales trabajar. De nada por el consejo.
#11 Para no desvelar tus comunicaciones ante terceras partes y asegurar que no inyectan código malicioso. Puede que para una web concreta no lo necesites pero, desde el punto de vista de cyberseguridad, es importante no revelar qué comunicaciones son seguras/importantes y cuáles no.
HDP
Por no decir que estar mostrando el aviso de marras, y darle al botón de excepción siempre por costumbre y sin mirar, se va a hacer ahora mucho más, y eso sí que es inseguro
La seguridad es necesaria, y por norma general se deben securizar los canales. Pero veo absurdo que un navegador obligue a usar https, como muchos indican es innecesario en segun que contenidos. Si quieres mostrar un texto plano público sin java, sin base de datos y que no requiere securizar el canal, para que obligarte a usar https?
Los "candados" son importantes para la información importante, pero imaginan que obligasen a poner candados a un cartel de "Alquilo plaza de garaje".. es absurdo si te sobra con atarlo con una brida.
Si alguien sabe un poquito de seguridad y se ha leido los RFC, podrá comprobar que hasta en servicios de PKI (TSA, OCSP y CRL) que son infraestructuras donde se exige los mas estrictos niveles de seguridad, en OCSP por ejemplo no se exige la obligatoriedad de https, quizás con el tiempo se obligue. Pero que lo exija el navegador...
La medida es clara: falsa sensación de seguridad y privacidad (más lo último)
#16 no entiendo por qué pasar de http a https jode una plantilla. Por el concepto"plantilla" en sí mismo, entiendo que tienes un CMS o una tienda online.
Supongo que tu web funciona (como todas) con un servidor (al que puedes instalar Let's Encrypt por ejemplo), una "carpeta" de archivos (donde tendrás un CMS o los html o PHPs o la tecnología que uses, que aquí como mucho tendrás que tocar en código cuál es la nueva URL del sitio, cambiando http por https) y una base de datos (donde reemplazar todas las llamadas http por https con un margen de error bajísimo)... es decir, ¿por qué tu plantilla se jode por tocar en el server, en la base de datos y a lo sumo en un par de líneas de código de la propia web?
Por otro lado, si lo de que se te jode la plantilla te lo ha dicho tu proveedor de hosting, cambia de proveedor. Si como sospecho, tienes un WordPress, el combo completo se hace en 15' con un margen de error en imágenes (que siguen siendo llamadas por http en lugar de https) de menos del 5%. Con esas toca machacarlas a mano... aunque yo, de todas las migraciones que he hecho en un año, no he tenido ni un solo problema con imágenes. Al hacer el reemplazo en base de datos todo ha pasado a "llamarse" por https.
Amplía información por favor
#75 hombre es que ofrecerlo tiene un coste en el rendimiento del sistema que en el caso de miles o millones de conexiones no es nada despreciable. y por desgracia nadie regala CPUs ni electricidad
#87 vale, tu tienes 27 visitas por segundo y no tiene apenas impacto pero nosotros tenemos mas de 15000 conexiones simultaneas y hemos tardado años en poder soportar SSL. y una empresa de hosting puede tener muchas mas
#126 utilizamos balanceadores de carga y granjas de servidores para distribuir la carga de los 15000 clientes conectados de forma simultanea, pero seguro que es comparable con un servidor con 27 conexiones simultaneas y nuestro departamento de redes y sistemas esta equivocado. porque activar el SSL no implica ningun gasto de recursos que lo has comprobado tu en tu servidor apache ejecutando el comando free. paso de perder el tiempo..
#131 ya te he dicho que estamos todos equivocados, y no usamos SSL porque somos demasiado tontos como para leer un pdf y mucho menos lidiar con la complejidad de configurar un servidor con nginx.. vamos que es un milagro que no nos clavemos el tenedor en la cara al comer
#55 Y sobretodo un detalle, una web en la que no te logeas para nada, ni compras nada, simplemente ves contenido, no se para que cojones necesita https.
#21 el cetiificado lo maneja el servidor (apache, nginx, iis...) Si la web está medianamente bien hecha debe funcionar con https sin problemas. El mayor problema seria que los enlances internos redirigieran de vuelta a http.
#19 #17 lo uso desde hace un año en mi server y es gloria bendita. Tengo muchos clientes que llegan preocupados por el tema de https sobre todo por posicionamiento pero para según que wes, que no guardan contraseñas, me parece excesivo pagar un certificado. Con esto tengo todas mis webs en https (incluso las que no estaban antes, aunque eso tiene un poco más de tareilla)
#16 que te joda, porque no quieres cambiar un par de cosas, no quiere decir que sea innecesario.
#16 Pues siento decirte que entonces no está muy bien hecha tu web, plantilla, melón, caja de zapatos o lo que sea que tengas.
#13 el Https pueden ser hackeado por un Man-in-the-middle. Precisamente el Man-in-the-middle es para eso. No puede ser hackeado con ataques más sencillos que si funcionan en no Https.
Does HTTPS prevent Man In The Middle attacks?
Posted on October 8, 2015 by eric
A common belief is that the HTTPS protocol prevents so-called Man In The Middle (MiTM) attacks. Unfortunately, in some circumstances, this assumption is wrong.
https://eric-diehl.com/does-https-prevent-man-in-the-middle-attacks/
tampoco uso chrome y soy muy feliz.
#26 es u a web irrelevante en donde solo leo o, si escribo algo, el contenido va a ser publico.
Lo del codigo malicioso me convence mas.
#35 yo he tenido que pasar algun sitio Zend del 2000 a https...y alguno de la epoca hecho a manubrio, y no ha sido mas de 1 dia de curro
#31 el día que lo metieron hice barbacoa y todo
#23 son los antivacunas del mundo informático. No tienen remedio
Ya esto me genera problemas con Chrome porque muchas configuraciones muchos controles de muchos equipos técnicos lo hago en plataforma web y cada vez que entro por primera vez me dice que un sitio inseguro blablablablabla
No sé si habrá una forma de saltarse porque la verdad estoy cansado
#34 yo sé porqué lo digo.
#24 https no es 100% efectivo, pero casi. Es prácticamente imposible romper el certificado, la única forma es engañar al navegador para que acepte un certificado no válido, que es lo que explica tu enlace.
No tiene sentido comparar algo tan rebuscado con el “todo abierto” de http, donde es imposible detectar ninguna modificación del contenido ya que no hay ningún tipo de cifrado.
#73 o tiene una pagina web que ha hecho el para sus mierdas o su curro (que intrusismo es ese). Y como no le gusta la programacion de paginas web. Como a ti. Pues le da pereza. De los peores troles de la historia. En serio. Tú.
#62 A la empresa donde trabajo la dejó con el culo al aire cuando decidió no admitir plugins npapi en su navegador. Tuvimos que migrar a Iexplorer.
#20 vaya, vaya, así que complicar las cosas para que usuario de a pie no pueda hacer las cosas y tenga que recurrir a "profesionales". Claro como las bombillas de los coches, las baterías de los móviles, y todas esas cosas que antes podía apañar uno mismo y ahora no.
Curioso nick el tuyo.
#1 https es porno con condon.
#35 Por que lo dices?
La estupidez del año patrocinada por Google Chrome.
#6 21 dic. 2016. La encriptación SSL será obligatoria a partir de 2017. Como venimos comentando últimamente en nuestras noticias, nos vemos en la obligación de recordar que la encriptación SSL ya no es algo opcional, es algo obligatorio. Dependiendo del tipo de sitio web, durante el año 2017 los navegadores penalizarán aquellos que no dispongan de encriptación SSL.
https://www.redalia.es/noticia/la-encriptacionssl-sera-obligatoria-a-partir-de2017-0018/
#15 https://lawebdetuvida.com/wordpress-https-lets-encrypt
Tiene pinta de ser super jodido poner SSL en Wordpress. Y carísimo.
#16 solo tienes que cambiar los enlaces internos a URL absoluta sin incluir el dominio. Si redireccionas a https mwdiante htaccess (por ejemplo) perderias los datos en todas las peticiones POST
#42 solo él lo sabe
#11 No hace falta que la web tenga formularios, sin https, mediante un ataque MitM, como dice #13, te pueden inyectar malware, sustituyendo cualquier script de la página por uno infectado, por ejemplo jQuery. Y con esto y aprovechando otros fallos de seguridad (Saltándose el sandbox del navegador, difícil pero no imposible) te pueden hacer un traje en el PC, por ejemplo robándote contraseñas, instalando minadores, adware, etc.
#16 yo he pasado 3 o 4 webs de http a https en lo que va de año, todas de su padre y de su madre, ninguna mia hecha de 0. Y no es para nada complicado. Como ya te han dicho, como mucho hay que cambiar http por https si tienes enlaces absolutos (Buscar y reemplazar, y añadir la S). Si usas enlaces relativos no hay que hacer absolutamente nada, tan solo cambiar la configuración del servidor. Si tienes reescritura de URLs te tocará modificar la configuración del servidor o del sitio, en el fichero .htaccess en el caso de Apache, o donde corresponda.
Tarde o temprano te va a tocar pasar por el aro, así que cuanto antes empieces mejor.
#11 #66 por eso precisamente se trata de evitar un man in the middle con el https
Porque en teoría el de la web “normal” que no quiere Joder a nadie no hace eso, y si por https lo evitas, evitas que hagan lo que dice #66
En resumen, que se pongan de teléfono roto entre medio del servidor de la página y tú, y cambien algunos mensajes sin que te enteres, para infectarte (resumen a pie de calle)
#65 El path de la página va cifrado, pero el dominio no. Pueden saber perféctamente que estás visitando www.meneame.net y por cuanto tiempo, aunque no puedan ver las URL completas.
#79 #89 la clave la está dando #67 respecto a esas redirecciones a https mediante 301: son redirecciones que provocan la perdida de los datos post (por qué tendrían que enviarse bajo https)
Esto por ejemplo en un caso particular mío es un problema importante: webservice con unos 250 clientes integrados apuntando a una dirección sin http, con unas 20-30 conexiones por segundo al endpoint y funcionamiento 24x7.
Primero, que meterle mano a ese código (ya muy antiguo) es un problema de base puesto que efectivamente se montan enlaces con http "hardcoded".
Segundo, y más importante, los clientes que se integraron hace años se ven obligados a hacer un cambio de su lado lo cual puede llevar tiempo.
#98 hombre, inmune a todo tampoco, https en su versión más básica, "solo" te asegura que el dominio de destino y el servidor que sirve el certificado coinciden y que la comunicación con este servidor va cifrada.
A partir de ahí pueden existir otros muchos problemas en los que el SSL no tiene nada que ver.
#11 Sirve para evitar que otros conozcan qué paǵinas visitas, además, en las páginas en las que se pueden dejar comentarios, para conservar tu anonimato.
Pues ya se podrían entretener en poner a la FNMT como autoridad certificadora en android
#10 Ni lo serán por mucho https que añadan
#13 https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html
De todas formas, con que finalidad quieres evitar el MITM o para que queria alguien hacertelo en una web irrelevante?
#19 En según que hostings no te lo permiten, por lo general el SSL es un negocio para los proveedores.
#85 Nada asegura invulnerabilidad a nada.
#1 pornhub es https
#80 Desinstalar Chrome suele funcionar.
#83 No se si lo dices de coña pero el hecho de servir páginas en SSL tiene un coste de CPU mínimo. Ahora mismo tengo un apache sirviendo 27 pag/sec de media con una carga cpu 2.20 y el balanceador nginx por delante que está haciendo todo el paso de http a https apenas tiene 0.08.
#72 ¿Qué parte de Wordpress no has entendido? ¿Montarse uno mismo una web en Wordpress es intrusismo? No sé en qué planeta vives.
#38 No digo que sea jodido ni caro, pero una mañana me tiraré fijo. Gracias por el enlace.
#78 ¿Y en páginas que no son segura pero que enlazan con pasarela de pago del banco (embebida dentro de la página principal), qué?
#37 Downgrandear una conexión https se soluciona con el HSTS, como dice en el artículo que mentas. Y desde 2016 ha llovido mucho. No me puedo creer que hables de carga del servidor cuando cifrar una conexión no es nada comparado con la latencia de leer del disco duro. La CPU está para usarse y si tienes que contratar algo más potente, se contrata. Miedo me da que haya gente que piense que el https es una medida exagerada
#1 si quieres porno seguro ponte gomita
#19 y hay hasta plugin gratuito en Plesk, que se instala en 2 clicks
joder con los antivacunas informáticos.
#98 no discutas, estos te están diciendo que vacunarse no está guay porque aún así, puede coger la enfermedad (se han dado casos) y por tanto, dado que hay un 0,000000001% de posibilidades de fallo, para que vacunarse?
Lo mismito
#20 quitar el símbolo de seguro no parece muy buen idea
#32 no recuerdo ninguna infeccion de ese tipo aprovechandose de un MITM pero si recuerdo unas cuantas aprovechandose de los anuncios y eso se puede hacer con https igual que sin el.
Pero bueno, podria ser un vector menos, el dia que el 95% de las webs implementen correctamente https y no como ocurre en el enlace que puse.
El problema es que https añade carga extra al servidor y en peticiones pequeñas pero abundantes, algo se nota.
A mi me sigue pareciendo exagerada la medida.
#34 En Plesk hay una opción en la configuración de dominio para que todas las peticiones con protocolo http sean convertidas automáticamente a https, así que sin problemas:
Sitios web y dominios -> Configuración de hosting -> Redireccionamiento 301 permanente de HTTP a HTTPS preservando SEO
Una vez más, Google sujeta la bombilla y el resto damos vueltas a la casa.
¿Desde cuándo una empresa privada y ajena nos dice qué protocolos tenemos que usar? ¿Es que acaso trabajamos para ellos?
#60 estoy de acuerdo.
#102 Lo de que Google, Facebook & co te puedan seguir rastreando con sus beacons lo obviamos, ¿no? Y que el mayor suministrador de certificados de bajo o nulo coste sea la gran G, tambien
#107 Tu hablas de lo técnico, yo de la parte de usuario y falsas sensaciones. Que una conexión esté tunelizada no quita para que lo que pase a través de ella sirva para rastrearte, o que un tercero que lo está haciendo tenga las llaves de todo el chiringuito
Eso es falsa sensación de privacidad
#8 pensaba eso desde que lo supe y lo sigo pensando. No puedo pasar a http sin cargarme la plantilla que tengo ahora. Seguramente seguirá el descenso de usuarios por culpa de esto que es totalmente innecesario.
#28 Para que no te infecten la computadora con un zero-day en javascript de tu navegador, que los hay.
#34: ¿Y si colgaste una página web y no tienes ganas de andar enredando?
Más que nada, porque no ganas dinero con ello, tampoco obtienes reconocimiento, y no vas a estar trabajando gratis porque a Google o a otros expertillos les venga bien.
Y respecto al coste, en la página web pone esto: "Donate". ¿Qué pasará el día en que no haya suficientes donaciones? Además, es forzar a la gente a depender de terceros.
#3 Así que sí va por Gopher es porno seguro... tomo nota .
#3 que risa Dios Pio !!!
Ahí va una pequeña lista de páginas con http:
Alibaba.com FoxNews.com
Dictionary.com Hilton.com
TheHill.com Washington.edu
RedCross.org Fortune.com
NYU.edu CBSLocal.com
NetworkAdvertising.org ChicagoTribune.com
Example.com Wikia.com
AllAboutCookies.org NOAA.gov
WorldBank.org Cornell.edu
Ox.ac.uk (Oxford) UN.org
UCLA.edu CA.org
ScienceMag.org Photobucket.com
Entrepreneur.com StarwoodHotels.com
MIT.edu BBC.com
Apache.org LATimes.com
Time.com TypePad.com
DailyMail.co.uk Go.com
Digg.com Gravatar.com
Bueno, no mienten, si van por http no son seguras.
#48 #58 si, como poder se puede, pero al redireccionar se pierden los datos transferidos en POST o RAW
¿Alguien ha calculado el coste medioambiental de esta medida? Lo digo en serio. Además del coste implícito que tiene sobre la libertad y neutralidad de la red. Un gigante tecnológico tratando de imponer su criterio a la fuerza (tenga o no razón). Si fuera Microsoft ya estaríais quemando fotos del amigo Bill.
#17 ya te puedes certificar gratis con letscript y google es patrocinador. No estar certificado es para una web decente, pereza. Para la web de «tu primo» igual es falta de conocimiento (solventable).
#17 lets encrypt y son gratuitos
#30 Ah... Pero hay montones de metadatos (e información de cuentas ya de usuario) que se transmiten pero no se publican. Y también es verdad que muchos sistemas de seguimiento (no necesariamente cookies) quieren estar seguros de que tú eres quien dices ser.
#37 con http 2.0 no hay excusa, que va todo multiplexado por una única conexión
#85 No lo asegura pero lo hace muchísimo más complejo. Necesitas manipular la cadena de confianza del navegador para que este se coma con patatas un MitM y para eso necesitas acceso al host atacado.
#38 Vale, no ha sido tan grave. Un par de intentos infructuosos, darle a un botoncito aleatorio en el cpanel, plugin y ya funciona.
Gracias. Mientras #73 se revuelve en su tumba. Si es que ha muerto, sino se revuelve en su silla o si está de pie se revuelve de pie.
Una conexión http es siempre una conexión no segura. Ahora bien una web con https no significa que sea segura. Primero si se hace la idiotez de mezclar contenido mixto http y https, por otro lado si se usan algoritmos o protocolos no seguros. Por eso hay webs que algunos navegadores aún con https las marcan como inseguras. También si un certificado es falso o está caducado, claro.
Salu2
#74 #66 #13 Es significativo que #70 me tuviera que poner como ejemplo la Pwn2Own en vez de casos en el mundo real, cuando yo puedo poner 1.unos 2.cuantos de 3.malvertising en el 4.mundo real.
Entonces tenemos que el https evitará un MITM para que no te puedan inyectar malware, que representa un ¿5%? de los casos reales, pero seguiremos teniendo otras técnicas como el malvertising que se están usando en el ¿95%? restante. ¿Es así? Si es así, poco (nada) va a solucionar el https.
#133 Me he perdido con tanta metáfora y no he entendido nada.
En cuanto a tu última frase, ¿por qué dices que "llegar a ese tipo de ingeniería de software para crear un virus, no es tan fácil.... "? si lo más fácil es justamente el malvertising y eso no se soluciona con https.
#137 Jeje, estás loco.
#141 hombre, como ya dije, con el malvertising un tercero malicioso puede inyectar malware sin que el dueño quiera y el https no impide eso.
#143 Sí, te garantiza que el html que recibes sea auténtico pero al malvertising le da igual porque el malvertising no cambia para nada el html original, no lo necesita, ya sea a través de simple http o https.