HTTP SSL Crypto Certificados Flashcards
Arquitectura de internet: TIER 1
Backbone, a nivel mundial. Acuerdos peering, interconexión libre y gratuita entre las entidades que lo componen. Grandes empresas
Arquitectura de internet: TIER 2
Regional, a nivel de país.
Arquitectura de internet: TIER 3
ISP, proveedores de internet locales.
Relaciones entre los TIER
No hay conexión directa entre los Tier1 y Tier3. Se realizan acuerdos de transito entre los de Tier1 y Tier2.
A su vez los de Tier2 pueden contratar los servicios de un Tier1 para que su tráfico tenga alcance internacional
Peering publico y privado
El peering público generalmente se lleva a cabo a través de un Punto de Intercambio de Tráfico de Internet (IXP), donde una red puede conectarse con varias redes a través de una sola conexión. El peering privado es cuando dos o más redes acuerdan intercambiar su tráfico en una instalación privada.
¿Qué es IXP?
Internet Exchange Point, Punto Neutro o Punto de Intercmbio de Internet. Gratuito, solo se paga por el servicio pero no hay un control corporativo. Son puntos en Tier2 muy usados por servicios de internet distribuidos (Netflix, interesa está cerca por latencias y tiempo de servicio).
Se puede pensar como una cooperativa, se pagan los gastos de mantenimiento del IXP
¿Qué es un CDN?
Content Delivery Network. Distribuir copias del contenido por IXP para tener el contenido cerca del cliente/usuario de tal manera que no tenga que viajar lasgas distancias y que no se haga embudo en un solo servidor (Netflix, Prensa etc. ) . Para tráfico importante, se paga.
¿Que son Sistemas Autonomos dentro de la arquitectura de internet?
AS. El número de sistema autonomo ASN es asignado por AIANA a cada ISP (Internet Service Provider) dentro de internet.
Cada ISP ‘dentro de su casa’, en su red, puede usar los protocolos de encaminamiento que quiera. Típicamente usamos los IGP como OSPF, RIP, IGRP.
Para comunicación entre ISP usamos los EGP, como puede ser BGP.
Protocolo HTTP evolución
NOTA: En HTTP/3 vemos que va sobre UDP con lo que no se garantiza la entrega. Para ello metemos una capa QUIC que se encarga de la gestión de errores SOLO cuando los haya de manera que las conexiones son más rápidas que con TCP
NOTA: Vemos que la semantica nocambia a lo largo de las generaciones de HTTP.
Caracteristicas Semanticas de HTTP
- Sin Estado: Cada petición que se hace al servidor es como la primera. El server no es capaz de saber si ya se ha visitado. Uso de cookies para suplir esta caracteristica.
- Orientado a caracter
- Módelo request - response
¿Qué son las Cookie?
Es un ‘código’ que almacena tu navegador en local, de tal manera que cada vez que hagas una petición a un servidor este sepa quien eres y pueda mantener datos de sesión sin perferlos. Ejemplo: carrito de compra de Amazon.
[PETICION C –> S]
header(request)
+
http://amazon.como/…./…./login
+
body(user=dani&passwd=….)
[PETICION C <– S]
header(response)
Set-Cookie: sessionid=asd9867sdf98asdf8545
body
[PETICION C –> S]
header(request)
Cookie: asd9867sdf98asdf8545
+
http://amazon.como/…./…./addProducto?id=100
+
body
*** Cookies mandadas por el server
Set-Cookie: <cookie-name>=<cookie-value>;</cookie-value></cookie-name>
- Secure –> La cookie es mandada al server solo cuando el canal es seguro.
- HttpOnly –> Impide que el codigo JavaScript acceda a la cookie.
- SameSite –> le permite declarar si su cookie debe restringirse a un contexto propio o del mismo sitio
- Expires –>El tiempo de vida máximo útil de una cookie
- Max-age –> Número de segundos hasta que la cookie expire
- Domain –> Host donde la cookie será enviada.
Cabeceras HTTP Request
Estas cabeceras las manda el navegador.
- Authorization: Se habilita en el servidor y nos pide autenticacíon por defecto y nosotros se la mandamos en este campo. La pantalla básica que nos sale en le navegador.
- Cache- Control: no-cache
- Accept: text/html –> Entiendo html
- Accept-Charset: utf-8 –> Entiendo utf-8
- Accept-Language: es-ES –> Entiendo el idioma español
- Accept-Enconding: gzip, defaflate –> Puedes mandarme contenido comprimido
- Content-Type: Contenido del body (contenido formulario, ficheros adjuntos etc)
- Content-Length: Longitud de lo que te estoy mandando en el body
- Cookie: Mandamos todas las cookies del dominio. Todas las que nos haya establecido el servidor.
- Date: Fecha / hora
- Host: Host al que estamos haciendo la petición. Hay que tener en cuenta que una misma dir ip podemos tener varios sites y la url que ponemos en nuestro navegador cuando se resuelve nos da la ip y cuando la petición nos llega al servidor no sabríamos el site. Ej.:
Estos dos sites podrían estar alojados en el mismo servidor pero nuestra petición solo iría a uno de ellos.
www.ruinosa.es –> 185.10.10.3
www.acme.com –> 185.10.10.3 - Range: Se puede especificar uno trocito del contenido. Ej.: cuando quieremos ir a una punto de un video, este no se descarga todo sino desde donde le hemos pedido.
- Connection: Keep-Alive
- User-Agent: Identifica al browser
Cabeceras HTTP Response
Estas cabeceras nos las manda el servidor
- Cache-Control:
- Content-Disposition: attachment. Si te mando un adjunto o no. Ej.: cuando en una web un pdf te lo descargas y en otra el pdf te lo muestra.
- Content-coding: gzip. Con que encoding te mando la información
- Content- Lenght: del body. Tamaño del body
- Content-Range: bytes 2100-3000. Rango de datos que te estoy mandando.
- Date: Fecha / hora
- Location: url (para direcciones). Cuando nos redirige a otra dirección.
- Transfer-Encoding:
- Last-Modified:
- WWW-Authenticate: BASIC. Manda la primera vez que nos conectamos al servidor si debemos autenticarnos con la Basic Authentication.
Códigos de respuesta HTTP
Códigos de error que nos devuelve el servidor
- 100’s: Informativos
- 200’s: Códigos de exito.
- 200: ok típico
- 201: Created. Se ha creado el recurso. Ej.: PUT
- 202: Accepted. Recibido pero no procesado. Ej.: Proceso batch
- 300’s: Redirecciones.
- 301: Se ha movido permanentemente. Location
- 302: Se ha movido temporalmente. Location
- 304: No se ha modificado desde la última request.
- 400’s: Problemas sobre la solicitud del cliente
- 400: Bad request. Petición mal construida
- 401: No autorizado. Requiere auth al cliente. Basic Auth
- 403: Prohibido. Cuando las creedenciales no son correctas
- 404: Not found. El recurso ya no existe.
- 405: Método no permitido (sobre ese recuso). Ej.: DELETE
- 413: Request muy grande. Ej.: Adjunto muy grande
- 500’s: Error o problema al procesar la solicitud en el servidor.
- 500: Internal error. Error no controlado
- 502: Bad Gateway. No encuentro el servidor java/php etc
- 503: Servicio no disponible. Cómo 500 controlado.
Tipos de URI
- URL (Uniform Resource Locators) Localizar –> http://…/…/…
- URN (Uniform Resource Name) Identificar –> urn:isbn:444-abc-123
Verbos HTTP
- GET: Solicitamos un recurso
- HEAD: Solo las cabeceras de un recurso
- PUT: Mandas al servidor. Reemplazado de un recurso fijo.
- POST: Mandas al servidor. Creas en el servidor un nuevo recurso.
- PATCH: Mandas al servidor. Reemplazado parcial de un recurso fijo.
- TRACE: Echo. Mandas una cadena y el servidor la devuelve. Es como un Ping
- OPTIONS: Pregunta al servidor que verbos puedo usar con el recurso.
- DELETE: Borrar un recurso.
- CONNECT:
¿Qué son médodos seguros? ¿Cuales de los verbos HTTP lo son?
Los request method son considerados seguros cuando en su definición semantica son solo de lectura (read-only) no hacen modifcaciones:
- GET
- HEAD
- OPTIONS
- TRACE
¿Qué significa que un método sea idempotente? ¿Cuales de los verbos HTTP lo son?
Los request method idempotentes son aquellos que ante distintas llamadas iguales, con los mismos datos de entrada, siempre darán la misma respuesta. Ojo!! pueden modificar pero siempre lo harán de la misma manera. Ej.: Un borrado de un recurso dejará el servidor con el estado borrado. Si lo volvemos a lanzar el servidor quedará en estado borrado, se queda en el mismo estado.
- Los métodos seguros son idempotentes por definicion: GET, HEAD, OPTIONS, TRACE
- PUT
- DELETE
¿Qué es la autenticacion BASIC?
La pide el servidor y nuestro navegador nos muestra un form por defecto. El navegador posteriormente manda esas credenciles
La pantalla básica que nos sale en le navegador.
Politica de seguridad CORS
Cross-Origin Resource Sharing” (Compartir Recursos entre Orígenes Cruzados)
Es un mecanismo de seguridad implementado por los navegadores web para permitir que los recursos de una página web sean solicitados desde otro dominio que no sea el dominio desde el cual se originó la propia página.
Para protegerse de peticiones a otros dominios, cuando el navegador ha hecho una primera conexión a un dominio al que nos referimos ‘como origin’. Se piden recursos a otros dominios con origin al valor incicial, y estos nuevos dominios pueden decidir no darnos la información.
(Ej. Te descargas la home de http://marca.com pero esta tiene referencias de css, imagenes, js, etc. a url’s como esta à https://cdnjs.cloudflare.com/ajax/libs/…/bootstrap.min.js)
Politica de seguridad HSTS
HTTP Strict Transport Security.
El servidor declara que solo se puede interactuar con el de manera segura y cambia el canal ordinario a TLS/SSL (pasa de http a https).
El servidor y todos sus enlaces.
Politica de seguridad CSP
Content Security Policy.
El servidor manda la cabecera Content-Security-Policy, describiendo de donde nos tienen que llegar ‘que’ recursos. Cualquier recursos que no nos llegue de los dominios indicados en la cabecera Content-Security-Policy es desechado. Esto mitiga los ataques Cross-site Scripting de inyección de código.
Cross-site Scripting (XSS)
Tipo de ataque informatico que permite a un actor de amenazas ejecutar codigo malicioso en el navegador de otro usuario. Explota la vulnerabilidad de un sitio web que la victima visita.
HTTP/2
- Basado en SPDY (Google)
- Podemos mandar en el mismo flujo (stream) de datos los frames desordenados y en destino se ordenan. Ej.: cabecera A, script B, body c, body A …
- Todos los Frames de un Stream llevan el mismo identificador para que el cliente pueda recostruir la información
- Es más rapido porque aprovecha mejor la rede que HTTP/1
- Fundamentalmente hay dos tipos de Frames: DAta y HEADERS
- Una única conexión TCP
- Permite Server Push
- No requiere TLS (Opcional). OJO!!! cuando vamos sin seguirdad al navegador llegará h2c y con seguridad h2. La versión de TLS tiene que ser 1.2 +
