Perguntas[http](server)

Meu CMS gera páginas bastante complexas e, portanto, demora um pouco para fazê-lo (cerca de 2 segundos), o que está bem acima do meu orçamento de tempo para fornecer páginas ao cliente.

Porém é muito barato para mim saber a versão atual de uma determinada página e é muito fácil para mim dizer se uma determinada versão ainda está atualizada. Como tal, eu gostaria de poder colocar uma estratégia baseada em ETag onde cada solicitação para uma página precise ser revalidada, mas o servidor responderá em no máximo 10 ms se o conteúdo não mudar.

Para que isso seja eficaz, preciso compartilhar esse cache entre todos os meus clientes. Enquanto a ETag for revalidada, todas as minhas páginas permanecerão idênticas para todos os usuários, para que eu possa compartilhar seu conteúdo com segurança.

Para fazer isso, minha página emite um:

Cache-Control: public, no-cache, must-revalidate
ETag: W/"xxx"

Ao testar em um navegador, funciona muito bem: a página permanece no cache e simplesmente é revalidada no servidor toda vez que atualizo a página, obtendo 304 na maioria das vezes ou 200 quando altero a versão do conteúdo.

Tudo que preciso agora é compartilhar esse cache entre clientes. Essencialmente:

1. Fase A
   1. O cliente A envia uma solicitação ao proxy
   2. O proxy não tem cache, então pergunta ao back-end
   3. Backend responde 200 com uma ETag
   4. O proxy responde 200 com uma ETag
2. Fase B
   1. O cliente B envia a mesma solicitação ao proxy
   2. O proxy está em cache, mas deve revalidar (porque não há cache, deve-revalidar e ETag)
   3. O back-end responde com 304 (porque a solicitação de revalidação inclui o cabeçalho If-None-Match com a ETag armazenada em cache)
   4. Proxy responde 200 com um Etag
3. Fase C
   1. O cliente A envia a mesma solicitação novamente, desta vez com If-None-Match
   2. O proxy solicita ao back-end o cabeçalho If-None-Match fornecido (não o armazenado em cache)
   3. O servidor back-end responde 304
   4. O proxy responde 304

Eu tentei o nginx, mas requer muitos ajustes para fazê-lo funcionar remotamente. Então experimentei o Traefik antes de perceber que o middleware de cache faz parte da versão corporativa. Então percebi que o Varnish parece implementar o que eu quero.

Então aqui vou eu com minha configuração do Varnish:

vcl 4.0;

backend default {
    .host = "localhost";
    .port = "3000";
}

backend api {
    .host = "localhost";
    .port = "8000";
}

sub vcl_recv {
    if (req.url ~ "^/back/" || req.url ~ "^/_/") {
        set req.backend_hint = api;
    } else {
        set req.backend_hint = default;
    }
}

E claro... Não funcionou.

Ao variar os Cache-Controlcabeçalhos, obtenho o resultado de um cache compartilhado, mas que não é revalidado, ou apenas uma passagem para o cliente, mas nunca parece manter o conteúdo em cache como gostaria.

O que estou faltando para implementar essa lógica de revalidação de cache/ETag compartilhada? Suponho que estou perdendo algo óbvio, mas não consigo descobrir o quê.

Percebi que enviar GET /(+CRLF) para alguns servidores da Web (por exemplo, de um provedor de pesquisa conhecido) resulta em uma HTTP/1.0 200 OKmensagem. Outro servidor da web responde com um HTTP/1.0 400erro.

Que eu saiba, até o HTTP/1.0 requer o campo de versão. É GET /(sem protocolo e host) uma solicitação GET abreviada válida e padronizada?

Após algumas pesquisas, descobri que o HTTP/0.9 de 1991 define o seguinte:

• Este pedido é constituído pela palavra "GET", um espaço, o endereço do documento,[...].
• O endereço do documento consistirá em uma única palavra (ou seja, sem espaços). Se mais palavras forem encontradas na linha de solicitação, elas DEVEM ser ignoradas ou tratadas de acordo com a especificação HTTP completa

Com HTTP/0.9 a requisição parece possível. Algumas fontes o chamam de protocolo de uma linha. Não tenho certeza se isso é senso comum ou não. Eu não sabia nem vi isso antes. Os servidores da web devem honrar essa solicitação HTTP/0.9?

Após um aumento na atividade de rede, verificando os logs do Apache que está atendendo a um site WordPress casual mínimo, por meio de um proxy Cloudflare, vejo a seguinte entrada repetida centenas de vezes:

172.71.98.180 - - [22/Aug/2022:01:59:06 +0000] "POST /wp-content/plugins/the-social-links/assets/css/font-awesome.min.css HTTP/1.1" 302 565 "-" "Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2"

Agora, os ataques HTTP não são novidade para mim, mas o estranho é que esse ataque está visando um recurso CSS com uma solicitação POST.

Como isso pode ser útil para o invasor de qualquer maneira possível?

Estou recebendo resultados HTTP 403 Forbidden inconsistentes ao solicitar imagens incorporadas em uma página da Web. Isso está acontecendo com mais frequência no FireFox, mas ocasionalmente também acontece no Chrome. Este site tem sido usado por muitos anos e isso só apareceu há algumas semanas. Eu controlo o site e o servidor e não tenho certeza de como solucionar esse problema. Quando atualizo a página, parece ser uma combinação diferente de recursos que causa o problema.

Resposta:

HTTP/1.1 403 Forbidden
Server: Microsoft-IIS/8.5
X-UA-Compatible: IE=Edge
X-Frame-Options: sameorigin
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000; includeSubDomains;
P3P: Our site does not have a P3P Policy, please see our privacy policy for more information.
Date: Fri, 15 Apr 2022 17:34:15 GMT
Content-Length: 0

Solicitar:

GET /bonds/images/exclamation.png HTTP/1.1
Host: <Redacted>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
Accept: image/avif,image/webp,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: <Redacted>
Cookie: <Redacted>
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
If-Modified-Since: Mon, 04 Apr 2022 20:03:08 GMT
Cache-Control: max-age=0

Eu realmente não sei por que minha configuração do nginx não funciona para www.

Minha configuração é:

server {
    listen 80;
    server_name postimg.cz www.postimg.cz;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443;

    server_name postimg.cz;

    # SSL Configuration
    ssl_certificate /etc/letsencrypt/live/postimg.cz/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/postimg.cz/privkey.pem;
    ssl_session_cache shared:SSL:10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GC>
    ssl_prefer_server_ciphers on;

    # See https://hstspreload.org/ before uncommenting the line below.
    # add_header Strict-Transport-Security "max-age=15768000; preload;";
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header Content-Security-Policy "frame-ancestors 'self'";
    add_header X-Frame-Options DENY;
    add_header Referrer-Policy same-origin;

    root /var/www/postimg.cz;

    # Disable access to sensitive application files
    location ~* (app|content|lib)/.*\.(po|php|lock|sql)$ {
        return 404;
    }
    location ~* composer\.json|composer\.lock|.gitignore$ {
        return 404;
    }
    location ~* /\.ht {
        return 404;
    }

    # Image not found replacement
    location ~* \.(jpe?g|png|gif|webp)$ {
        log_not_found off;
        error_page 404 /content/images/system/default/404.gif;
    }

    # CORS header (avoids font rendering issues)
    location ~* \.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$ {
        add_header Access-Control-Allow-Origin "*";
    }

    # PHP front controller
    location / {
        index index.php;
        try_files $uri $uri/ /index.php$is_args$query_string;
    }

    # Single PHP-entrypoint (disables direct access to .php files)
    location ~* \.php$  {
        internal;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    }
}

Mas quando eu vou para http://www.postimg.cz ele não redireciona para https://postimg.cz por que isso? Você pode me ajudar com isso?

Servidor: Ubuntu Server 20.04

EDIT // Tentei também isso, também não funciona:

server {
    listen 80;
    server_name www.postimg.cz postimg.cz;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name www.postimg.cz;
    ssl_certificate /etc/letsencrypt/live/www.postimg.cz/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.postimg.cz/privkey.pem;
    return 301 https://postimg.cz$request_uri;
}

server {
    listen 443 ssl;

    server_name postimg.cz;

Meu nginx.conf tem várias seções de "servidor" e uma seção de servidor pega-tudo. Aqui está um exemplo nginx.conf para dar uma ideia:

user www-data;
worker_processes auto;
worker_cpu_affinity auto;
pid /run/nginx.pid;

events {
    worker_connections 4000;
    use epoll;
    accept_mutex off;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    error_log /var/log/nginx/error.log;

    server {
        listen 80;

        server_name foo.com;

        location / {
            default_type text/plain;
            return 200 "hello from foo.com";
        }

        error_page 500 502 503 504 /500.html;
    }

    server {
        listen 80 default_server;
        server_name _;

        location / {
            return 403 "sorry";
        }
    }

}

Estou esperando que o servidor retorne 403 se o cabeçalho "Host" for qualquer coisa menos "foo.com".

Aparentemente, alguém está executando o Burp Suite no meu servidor, e notei um comportamento interessante quando eles enviam um cabeçalho "Host: foo.com:more-stuff-here": NGINX roteia a solicitação para a primeira seção "servidor". Parece que ele ignora os dois pontos e tudo depois dele no valor do cabeçalho.

Eu posso reproduzi-lo localmente com o nginx.conf acima:

$ curl -H "Host: foo.com" http://127.0.0.1
hello from foo.com

$ curl -H "Host: foo.com:unexpected-content" http://127.0.0.1
hello from foo.com

$ curl -H "Host: bar.com" http://127.0.0.1
sorry

Por que o NGINX faz isso? Esse é um comportamento esperado? O que devo mudar no nginx.conf para garantir que as solicitações com o cabeçalho "Host: foo.com:more-stuff-here" vão para o bloco padrão?

Atualização: para quem está pesquisando o mesmo problema, também criei um ticket no rastreador de problemas NGINX .

A porta http deve estar disponível para outro uso.
A porta 80 da página de estatísticas deve ser fechada ou movida para outra porta.
A remoção mode httpna defaultseção desativa a página. echo >/dev/tcp/hostname/80retorna '0' -> a porta 80 já está acessível.

Digamos que eu tenha um certificado TLS para um domínio, mas não tenho certeza se todos os agentes de usuário potencialmente conectados por HTTP o aceitariam. Posso obter outro certificado, assinado por outra autoridade de certificação, e usá-lo nesses casos como um fallback, de forma transparente para o usuário? Se for possível, como procederia a comunicação cliente-servidor para estabelecer uma conexão segura? E este caso de uso é bem conhecido e suportado na configuração de servidores HTTP populares?

Eu sei que existem perguntas semelhantes, mas eles perguntam sobre a variação do certificado usado por subdomínio (possível) ou prefixo de caminho (impossível IIUC porque no momento da negociação o servidor conhece apenas a autoridade, não o URI completo da solicitação).

Eu quero configurar o servidor de forma que a raiz do servidor sirva alguns arquivos estáticos, que um endpoing específico, /nextcloud serve nextcloud no mesmo domínio.

Aqui está meu nginx.conf -

worker_processes  8;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       80 http2;
        listen [::]:80 http2;
        server_name  localhost;
        root   /srv/http/;
        location / {
            index  index.html index.php;
            try_files $uri $uri/ =404;
            autoindex on;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }
    }
    include /etc/nginx/sites-enabled/*;
}

Aqui está meu /etc/nginx/sites-enabled/nextcloud.conf

upstream php-handler {
    server unix:/run/nextcloud/nextcloud.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name nextcloud;

    root /usr/share/webapps/;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    location ^~ /.well-known {
        location = /.well-known/carddav { return 301 /nextcloud/remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /nextcloud/remote.php/dav/; }

        location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
        location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

        return 301 /nextcloud/index.php$request_uri;
    }

    location ^~ /nextcloud {
        client_max_body_size 512M;
        client_body_timeout 300s;
        fastcgi_buffers 64 4K;

        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

        add_header Referrer-Policy                      "no-referrer"   always;
        add_header X-Content-Type-Options               "nosniff"       always;
        add_header X-Download-Options                   "noopen"        always;
        add_header X-Frame-Options                      "SAMEORIGIN"    always;
        add_header X-Permitted-Cross-Domain-Policies    "none"          always;
        add_header X-Robots-Tag                         "none"          always;
        add_header X-XSS-Protection                     "1; mode=block" always;

        fastcgi_hide_header X-Powered-By;

        index index.php index.html /nextcloud/index.php$request_uri;

        location = /nextcloud {
            if ( $http_user_agent ~ ^DavClnt ) {
                return 302 /nextcloud/remote.php/webdav/$is_args$args;
            }
        }

        location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)    { return 404; }
        location ~ ^/nextcloud/(?:\.|autotest|occ|issue|indie|db_|console)                  { return 404; }

        location ~ \.php(?:$|/) {
            rewrite ^/nextcloud/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /nextcloud/index.php$request_uri;

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            set $path_info $fastcgi_path_info;

            try_files $fastcgi_script_name =404;

            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;

            fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
            fastcgi_param front_controller_active true;     # Enable pretty urls
            fastcgi_pass php-handler;

            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;

            fastcgi_max_temp_file_size 0;
        }

        location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite)$ {
            try_files $uri /nextcloud/index.php$request_uri;
            expires 6M;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets

            location ~ \.wasm$ {
                default_type application/wasm;
            }
        }

        location ~ \.woff2?$ {
            try_files $uri /nextcloud/index.php$request_uri;
            expires 7d;         # Cache-Control policy borrowed from `.htaccess`
            access_log off;     # Optional: Don't log access to assets
        }

        location /nextcloud/remote {
            return 301 /nextcloud/remote.php$request_uri;
        }

        location /nextcloud {
            try_files $uri $uri/ /nextcloud/index.php$request_uri;
        }
    }
}

O problema é que essa configuração não funciona. Com esta configuração, recebo um 404 quando tento acessar /nextcloud/.

Se eu desabilitar o bloco do servidor de arquivos estáticos no nginx.conf, posso acessar /nextcloud/ mas não consigo acessar meus arquivos estáticos. Como configuro para que ambos funcionem, no mesmo host e na mesma porta?

O Nginx é colocado na frente de uma arquitetura de microsserviços sobre a qual não temos nenhuma visão. Recuperamos as métricas expostas pelo status do stub http e gostaríamos de calcular um indicador do desempenho da plataforma: Não podemos usar latência em um teste de carga, pois queremos comparar sites geograficamente diferentes.

O que tentamos até agora:

• Calcule um delta do total de solicitações por unidade de tempo. Problema: não reflete o desempenho, todos os sites tratam a mesma quantidade de solicitações (100req por 100ms)
• Use o medidor de conexões em espera*

*Com este indicador, observamos diferentes comportamentos. Os dois extremos são:

Servidor 2012 (E5-2620 v1, 24 threads): média de 68,62 conexões em espera por 100ms

Servidor 2021 (AMD EPYC 7642, 96 threads): uma média de 91,96 conexões em espera por 100ms

Primeira pergunta. Parece que o medidor deve ser lido como "quanto maior, melhor". Por quê? A documentação não dá detalhes mas, até onde sabemos, uma conexão esperando por uma resposta deve aparecer aqui. Ou esse medidor é composto apenas por conexões ociosas (ou seja, já atendidas)?

Segunda questão. Em um mesmo teste de carga, as métricas de conexão aceitas/tratadas são muito maiores no servidor mais recente (em torno do dobro). Por quê? Ambos atenderam ao mesmo número de solicitações enviadas por um pool de 100 conexões. O que vemos é que a quantidade de conexões manipuladas progride muito rapidamente no início, até um valor limite diferente dependendo da arquitetura, e depois a progressão é bastante linear. Não encontramos nenhuma explicação para este comportamento mostrado neste gráfico: gráfico de conexões manipuladas