HTTPS重定向，如何巧妙为疑问？

HTTPS是确保传输安全最主要的手段，并且已经成为了互联网默认的传输协议。不知道读者朋友们是否注意到当我们利用浏览器（比如Chrome）浏览某个公共站点的时候，如果我们输入的是一个HTTP地址，在大部分情况下浏览器会自动重定向到对应HTTPS地址。这一特性源于浏览器和服务端针对HSTS（HTTP Strict Transport Security）这一HTTP规范的支持。ASP.NET利用HstsMiddleware和HttpsRedirectionMiddleware这两个中间件提供了对HSTS的实现。（本文提供的示例演示已经同步到《ASP.NET Core 6框架揭秘-实例演示版》） [S2401]构建HTTPS站点（源代码） [S2402]HTTPS终结点重定向（源代码） [S2403]注册HstsMiddleware中间件（源代码） [S2404]设置HSTS配置选项（源代码） [S2401]构建HTTPS站点虽然目前绝大部分的公共站点都提供了HTTPS终结点，但是由于用户多年养成的习惯，以及客户端（以浏览器为主的User Agent）提供的一些自动化行为，导致针对站点的初始请求依然采用HTTP协议，所以站点还是会提供一个HTTP终结点。为了尽可能地采用HTTPS协议进行通信，“国际互联网工程组织（IETF）”制定了一份名为“HSTS（HTTP Strict Transport Security）”的安全规范或者协议，ASP.NET针对HSTS的实现是由THstsMiddleware和HttpsRedirectionMiddleware这两个中间件来完成的。接下来我们利用一个简单的实例演示来介绍HSTS旨在解决的问题，以及针对这两个中间件的使用。 HTTPS站点会绑定一张证书，并利用证书提供的密钥对（公钥/私钥对）在前期通过协商生成一个用来对传输内容进行加解密的密钥。HTTPS站点绑定的证书相当于该站点的“身份证”，它解决了服务端认证（确定当前访问的不是一个钓鱼网站）的问题。我们之所以能够利用证书来确定站点的正式身份，源于证书具有的两个特性：第一，证书不能篡改，附加了数字签名的证书可以很容易地确定当前的内容是否与最初生成时一致；第二，证书由权威机构签发，公共站点绑定的证书都是从少数几个具有资质的提供商购买的。 我们演示的程序涉及的通信仅限于本机范围，并不需要需要真正地从官方渠道去购买一张证书，所以我们选择创建一个“自签名”证书。自签名证书的创建可以采用多种方式，我们采用如下的方式在PowerShell中执行New-SelfSignedCertificate命令创建了针对“artech.com”，“blog.artech.com”和“foobar.com”域名的三张证书。 New-SelfSignedCertificate -DnsName artech.com -CertStoreLocation "Cert:\CurrentUser\My" New-SelfSignedCertificate -DnsName blog.artech.com -CertStoreLocation "Cert:\CurrentUser\My" New-SelfSignedCertificate -DnsName foobar.com -CertStoreLocation "Cert:\CurrentUser\My" 在执行New-SelfSignedCertificate命令的时候，我们利用-CertStoreLocation参数为生成的证书指定了存储位置。证书在Windows系统下是针对“账号类型”进行存储的，具体的账号分为如下三种类型，证书总是存储在某种账户类型下某个位置。对于生成在自签名证书，我们将存储位置设置为“Cert:\CurrentUser\My”，意味它们最终会存储在当前用户账户下的“个人（Personal）”存储中。 当前用户账户（Current user account）机器账户（Machine account）服务账户（Service account）我们可以利用Certificate MMC（Microsoft Management Console）查看生成的这三张证书。具体的做法是执行mmc命名开启一个MMC对话框，并选择菜单“File>Add/Remove Snap-In...”开启Snap-In窗口，在列表中选择“Certificate”选项。在弹出的证书存储类型对话框架中，我们选择“Current user account”选项。在最终开启的证书管理控制台上，我们可以在Personal存储节点中看到如图25-1所示的三张证书。