HTTPS protects communication between a client and an application by encrypting HTTP requests and responses with TLS. Without it, attackers on the same network can read or modify traffic, steal cookies, or expose passwords and personal information. HTTPS is effectively required for production applications. section 28.1 section 28.5
Choose the HTTPS arrangement that fits the application:
- Use the ASP.NET Core development certificate, or the IIS Express development certificate, for local testing. Trust the certificate with dotnet dev-certs https --trust. section 28.0 section 28.5
- Configure Kestrel with a production certificate through Kestrel:Certificates:Default. Kestrel loads it at startup without application code changes. section 28.0 section 28.5
- Terminate TLS at a reverse proxy such as IIS, NGINX, or a third-party service, or pass encrypted traffic through to the application. section 28.1 section 28.5
- Encourage browser clients to use HTTPS with HTTP-to-HTTPS redirection and HSTS. API applications should generally listen only for HTTPS because non-browser clients may not follow browser protections. section 28.4 section 28.4.3
HTTPS-only API endpoint
Configure the application URL with only an HTTPS address, such as ASPNETCORE_URLS=https://*:5001. The application then listens on port 5001 for HTTPS connections and does not handle HTTP requests. section 28.4.3
Figure 28.1 Unencrypted HTTP requests can be read by users on the same network. Attackers can even intercept the request and response, reading or changing the data. HTTPS requests can’t be read or manipulated by attackers.
Use the traffic comparison to see why unencrypted HTTP permits reading and manipulation while HTTPS protects requests and responses. section 28.1
