Puncte:0

Este sigur să vorbiți cu un API local cu http, când punctul final public este https?

drapel ng

Context

Am o configurare de server care arată astfel:

  • Un server Apache ascultă exemplu.com;
  • Port public 80 este redirecționat către 443;
  • Port public 443 este redirecționat către un proiect Symfony;
  • Pe aceeași mașină, există un server API local scris în Rust, care ascultă http://127.0.0.1:8030 (fără suport SSL/TLS);
  • API-ul local este capabil să răspundă la unele date sensibile, cum ar fi jetoanele de autentificare JWT;
  • https://example.com/api este un proxy pentru serverul API local (ProxyPass și ProxyPassReverse, vezi configurația Apache de mai jos), pentru a:
    • expuneți API-ul utilizatorului final cu suport SSL/TLS,
    • și să-i poată trimite cereri de javascript XHR, de pe site-ul public Symfony.

Notă: Am făcut această configurare cu un proxy pentru API-ul local pentru că am avut multe probleme cu regulile CORS; dar aceasta este nu subiectul întrebării mele (presupun că există setări mult, mult mai bune).

Întrebare

Această configurare poate fi considerată sigură sau ar trebui să fie un punct bun să adăugați suport SSL/TLS pentru API-ul local?

Configurație Apache, puțin simplificată

<VirtualHost *:80>
   ServerName example.com
   Redirect / https://example.com
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com

    DirectoryIndex /index.php

    ProxyPass /api http://127.0.0.1:8030/
    ProxyPassReverse /api http://127.0.0.1:8030/

    SSLEngine on
    SSLProtocol -ALL +TLSv1.2 +TLSv1.3
    SSLCompression off
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCACertificateFile /etc/letsencrypt/live/example.com/fullchain.pem

    DocumentRoot /var/www/html/symfony_project/public
    <Directory /var/www/html/symfony_project/public>
        AllowOverride All
        Require all granted
        Allow from All
        FallbackResource /index.php
    </Directory>

    ErrorLog /var/log/apache2/symfony_project_error.log
    CustomLog /var/log/apache2/symfony_project_access.log combined
</VirtualHost>
Puncte:0
drapel it

Depinde de permisiunea de acces la gazdă în sine.În cazul în care sistemul gestionează doar traficul http/https și niciun utilizator (cu excepția administratorilor) nu are voie să se autentifice, aș spune DA, este un design securizat...

Întrebarea este CINE și CÂND pot prinde potențial datele sensibile. Terminarea SSL se face oricum pe server, deci există o parte în care datele nesecurizate există oricum (de exemplu, RAM). Deci, până când sistemul este restricționat la acces și datele nesecurizate nu părăsesc sistemul (de exemplu, nu trec placa de rețea), datele vor fi în siguranță.

Stratul SSL pe conexiunea locală nu ar avea mare beneficiu, deoarece toate cheile sunt oricum localizate pe sistem. Resursa salvată la decriptarea/decriptarea traficului local poate fi folosită pentru o cantitate mai mare de conexiune pe care sistemul o poate gestiona...

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.