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/
#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)
#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
#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.
#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
#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.
#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.
#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
#89 se puede, aunque personalmente soy más de no poner el dominio en los enlaces internos (pa qué?)
Otra cosa es que tengas un iframe, ahí te tienes que comer el protocolo si o si.
#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.
#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.
#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).
#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.
#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.
#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.
#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?
#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.
#24 Pero es muchísimo más complicado de realizar. Como mínimo, necesitas crear un certificado para el mismo dominio, desde una CA en la que confíe el navegador del usuario.
#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.
#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
Pues puedes empezar por el Pwn2Own que hacen cada año, donde suelen caer TODOS los navegadores con ataques zero-day, obteniendo el control total del equipo en muchos de los casos.
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.
#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.
#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)
#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.
#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.
#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.
#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.
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...
#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.
#97 para que el juanker que se ha metido en tu wifi, o el otro juanker de la mesa de al lado en starbucks, o el mega juanker que ha comprometido la infraestructura de tu ISP no te haga un ‘man in the middle’ para ver tu historial de porno.
#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.
#54 Creo que te confundes de comentario, en ningún momento he hablado nada de lo que comentas.
Solo digo que este usuario (que según parece se vende como profesional de algo, tiene un portafolio) dice que "perderá" una mañana añadiendo a sus webs seguridad.
#72 chico, igual el usuario es profesional de la venta de pelotas de pingpong amarillas, y ha dedicado sus pocos o nulos conocimientos técnicos y su preciado tiempo a montar un WordPress y publicar ahí sus fotos de sus pelotas de pingpong, todas bien colocaditas con su perfecto color amarillo y su redondez absoluta. Pues me da que #54 tiene toda la razón
#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ú.
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.
#62 Los antivacunas online, los del "pues a mí me funciona" y los de "ya no tenemos libertad para pensar por mi mismo" haceros un favor y dejad de usar internet! Por vuestro bien.
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...
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
#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/
#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.
#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
#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
#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.
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...
#43 En absoluto! De falso nada. Pasas de no tener ninguna seguridad en absoluto a tener toda la seguridad deseable, toda la privacidad posible del protocolo y encima estar seguro frente a cosas raras.
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
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?
Que google obligue a meter un certificado y que google emita certificados gratis a través de letsencrypt que es el que usa la mayoría de webs que apenas tienen financiación seguro que no trae nada bueno.
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/
#19 y hay hasta plugin gratuito en Plesk, que se instala en 2 clicks
#31 el día que lo metieron hice barbacoa y todo
#76 y no invitaste... meneame está de capa caida
#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)
#19 En según que hostings no te lo permiten, por lo general el SSL es un negocio para los proveedores.
#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
#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.
#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
#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.
#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.
#17 y que hay de las webs antiguas o que no puedan adaptarse? No. Es exagerado totalmente.
#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.
#34 yo sé porqué lo digo.
#35 Por que lo dices?
#42 solo él lo sabe
#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
#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
#48 #58 si, como poder se puede, pero al redireccionar se pierden los datos transferidos en POST o RAW
#67 Esto suena a que deberías:
Redireccionar a https toda petición hagan a http
Eliminar cadenas harcodeadas a fuego con 'http://', sea en código sea en template.
Siguientes peticiones deberían ir sobre https sin problema
Se da por sentado que hay un certificado instalado correctamente.
No veo problema, veo mucho trabajo manual, pero no problema (a menos que el código dependa del protocolo, ahí clavado a fuego en algún lado)
#79 Lo suyo es hacer una modificación en todo el código y cambiar "http://" y "https://" por "//".
#89 se puede, aunque personalmente soy más de no poner el dominio en los enlaces internos (pa qué?)
Otra cosa es que tengas un iframe, ahí te tienes que comer el protocolo si o si.
#94 No hace falta poner el dominio.
Ejemplo:
Te va a funcionar independientemente del protocolo que se esté usando y va a respetar el protocolo.
#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.
#48 Eso te lo puedes hacer a mano usando una regla de mod rewrite en el htaccess/vhost. Entiendo de hecho que el plesk lo hará así.
#34 Siempre se puede redireccionar a https.
#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.
#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
#17 una pasta.. concretamente 7€ al año el último que compré.
#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/
#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.
#69 claro claro es muchísimo mejor que nada. Pero no asegura invulnerabilidad para un MitM
#85 Vale, ya lo has dicho. Y?
Https es inmune a todo, incluyendo MiM con la excepción de algún escenario concreto dentro del mismo tal y como explican en tu enlace.
#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.
#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
#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.
#85 Nada asegura invulnerabilidad a nada.
#24 Pero es muchísimo más complicado de realizar. Como mínimo, necesitas crear un certificado para el mismo dominio, desde una CA en la que confíe el navegador del usuario.
#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?
#28 Para que no te infecten la computadora con un zero-day en javascript de tu navegador, que los hay.
#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.
#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
#37 con http 2.0 no hay excusa, que va todo multiplexado por una única conexión
#37 ¿No recuerdas ninguno?
Pues puedes empezar por el Pwn2Own que hacen cada año, donde suelen caer TODOS los navegadores con ataques zero-day, obteniendo el control total del equipo en muchos de los casos.
https://en.wikipedia.org/wiki/Pwn2Own
#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.
#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.
#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)
#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.
#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.
#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.
#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.
#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.
no uso Chrome, gracias
Es de chiste pasarse por las webs de la administración del Estado y ver que casi ninguna es segura.
#10 Ni lo serán por mucho https que añadan
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...
#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.
#97 para que el juanker que se ha metido en tu wifi, o el otro juanker de la mesa de al lado en starbucks, o el mega juanker que ha comprometido la infraestructura de tu ISP no te haga un ‘man in the middle’ para ver tu historial de porno.
Aquí hay misticismo y magufería en todos lados.
Venga, a tirarme una mañana perdiendo el tiempo para ver cómo pasar mi puto portfolio en Wordpress a https. Gracias Google.
#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.
#20 quitar el símbolo de seguro no parece muy buen idea
#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.
#54 Creo que te confundes de comentario, en ningún momento he hablado nada de lo que comentas.
Solo digo que este usuario (que según parece se vende como profesional de algo, tiene un portafolio) dice que "perderá" una mañana añadiendo a sus webs seguridad.
#72 ¿Qué parte de Wordpress no has entendido? ¿Montarse uno mismo una web en Wordpress es intrusismo? No sé en qué planeta vives.
#72 chico, igual el usuario es profesional de la venta de pelotas de pingpong amarillas, y ha dedicado sus pocos o nulos conocimientos técnicos y su preciado tiempo a montar un WordPress y publicar ahí sus fotos de sus pelotas de pingpong, todas bien colocaditas con su perfecto color amarillo y su redondez absoluta. Pues me da que #54 tiene toda la razón
#15 https://lawebdetuvida.com/wordpress-https-lets-encrypt
Tiene pinta de ser super jodido poner SSL en Wordpress. Y carísimo.
#38 Por eso me da a mi que este es un intruso laboral o directamente se ha inventado el comentario.
#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ú.
#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.
#38 No digo que sea jodido ni caro, pero una mañana me tiraré fijo. Gracias por el enlace.
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.
#62 Los antivacunas online, los del "pues a mí me funciona" y los de "ya no tenemos libertad para pensar por mi mismo" haceros un favor y dejad de usar internet! Por vuestro bien.
#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.
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...
#23 son los antivacunas del mundo informático. No tienen remedio
¿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.
#3 que risa Dios Pio !!!
#3 Que le ponga un preservativo al http y asi tendra ya porno seguro . O casi seguro que lo tiene!
#3 Así que sí va por Gopher es porno seguro... tomo nota .
#1 pornhub es https
#1 https es porno con condon.
#1 you will get aids
#1 si quieres porno seguro ponte gomita
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
HDP
#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/
#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.
#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
#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.
#60 estoy de acuerdo.
#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
#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.
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)
#43 En absoluto! De falso nada. Pasas de no tener ninguna seguridad en absoluto a tener toda la seguridad deseable, toda la privacidad posible del protocolo y encima estar seguro frente a cosas raras.
De falso nada. Http es un protocolo inseguro.
tampoco uso chrome y soy muy feliz.
#4 Yo no uso pajaritas y también soy muy feliz
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
#80 Desinstalar Chrome suele funcionar.
La estupidez del año patrocinada por Google Chrome.
Pues ya se podrían entretener en poner a la FNMT como autoridad certificadora en android
joder con los antivacunas informáticos.
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?
Bueno, no mienten, si van por http no son seguras.
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
#53 Alibaba es segura y esta la primera, has revisado la lista?
#77 comprueba m.spanish.alibaba.com o BBC.com
#53 Esa lista es FALSA.
A mí me deja entrar en páginas inseguras "bajo mi propia responsabilidad". ¿Eso también lo van a quitar, o qué?
#92 Te van a mostrar eso en las páginas http. Yasta. Van a decirte que una web http es insegura, lo cual es 100% correcto por definición.
Si me permiten les daré dos consejos:
No compren en páginas que no sean https.
No usen chrome.
#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é?
Pues acabo de forzar la actualización para verlo y todo sigue igual
Que google obligue a meter un certificado y que google emita certificados gratis a través de letsencrypt que es el que usa la mayoría de webs que apenas tienen financiación seguro que no trae nada bueno.