Strict Transport Security (HSTS)

语法

Strict-Transport-Security: max-age=<expire-time>
设置在浏览器收到这个请求后的<expire-time>秒的时间内凡是访问这个域名下的请求都使用HTTPS请求。

Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
如果这个可选的参数被指定,那么说明此规则也适用于该网站的所有子域名。
Strict-Transport-Security: max-age=<expire-time>; preload
查看 预加载 HSTS 获得详情。不是标准的一部分
Strict-Transport-Security: max-age=31536000; includeSubDomains
//现在和未来的所有子域名会自动使用 HTTPS 连接长达一年

描述

一个网站接受一个HTTP的请求,然后跳转到HTTPS,用户可能在开始跳转前,通过没有加密的方式和服务器对话,比如,用户输入http://foo.com或者直接foo.com。

事例

你连接到一个免费WiFi接入点,然后开始浏览网站,访问你的网上银行,查看你的支出,并且支付一些订单。很不幸,你接入的WiFi实际上是黑客的笔记本热点,他们拦截了你最初的HTTP请求,然后跳转到一个你银行网站一模一样的钓鱼网站。 现在,你的隐私数据暴露给黑客了。

Strict Transport Security解决了这个问题;只要你通过HTTPS请求访问银行网站,并且银行网站配置好Strict Transport Security,你的浏览器知道自动使用HTTPS请求,这可以阻止黑客的中间人攻击的把戏。

浏览器如何处理

你的网站第一次通过HTTPS请求,服务器响应Strict-Transport-Security 头,浏览器记录下这些信息,然后后面尝试访问这个网站的请求都会自动把HTTP替换为HTTPS。

当HSTS头设置的过期时间到了,后面通过HTTP的访问恢复到正常模式,不会再自动跳转到HTTPS。

每次浏览器接收到Strict-Transport-Security头,它都会更新这个网站的过期时间,所以网站可以刷新这些信息,防止过期发生。

Chrome、Firefox等浏览器里,当您尝试访问该域名下的内容时,会产生一个307 Internal Redirect(内部跳转),自动跳转到HTTPS请求。

预加载 HSTS

谷歌维护着一个 HSTS 预加载服务。按照如下指示成功提交你的域名后,浏览器将会永不使用非安全的方式连接到你的域名。虽然该服务是由谷歌提供的,但所有浏览器都有使用这份列表的意向(或者已经在用了)。但是,这不是 HSTS 标准的一部分,也不该被当作正式的内容。

OAuth 2

https://developers.google.com/identity/protocols/oauth2#libraries

  • 先请求google 接口 跳转到Google 认证框,会带上自己的redirect 链接
  • 在google 同意框 里 确认后, 会重定向 自己的页面 而且url 会带有 访问 token 的code
  • 在页面url里拿到code 再次请求 Google 接口 获取 token
{
  "access_token": "HbkBrQ5TAJFYUeLWsjhgWZ1Qt-ov9F0_B0S92aDhCMTQ", 
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjZmY2Y0MTMyMjQ3NjUxNTZiNDg3NjhhNDJmYWMwNjQ5NmEzMGZmNWEiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJhenAiOiI0MDc0MDg3MTgx", 
  "expires_in": 3599, 
  "token_type": "Bearer", 
  "scope": "https://www.googleapis.com/auth/userinfo.profile", 
  "refresh_token": "1//KCgYIARAAGAQSNwF-L9IEcbqfjUdRQuK1y01gl2m4"
}
  • 然后拿着access_token 去请求 Google 接口用户数据

https://developers.google.com/accounts/images/webflow.png

Using OAuth 2.0 for Web Server Applications

https://developers.google.com/identity/protocols/oauth2/web-server

Service accounts

Google API(例如Prediction API和Google Cloud Storage)可以代表您的应用程序运行,而无需访问用户信息。在这些情况下,您的应用程序需要向API证明自己的身份,但无需用户同意。同样,在企业方案中,您的应用程序可以请求委派对某些资源的访问

您从Google API控制台获得的服务帐户的凭据, include a generated email address that is unique, a client ID, and at least one public/private key pair. You use the client ID and one private key to create a signed JWT and construct an access-token request in the appropriate format.  然后,您的应用程序将令牌请求发送到Google OAuth 2.0授权服务器,该服务器会返回access token。该应用程序使用access token访问Google API。当令牌过期时,应用程序将重复该过程。

Using OAuth 2.0 for Server to Server Applications

https://developers.google.com/identity/protocols/oauth2/service-account

cerbot 使用Certbot获取免费泛域名

所以目前我需求就是获取nginx上使用的.pem.key两个文件.

安装cerbot,并使用

获取泛域名文档  看他的泛域名文档,以下是安装总结

1. 使用snap 安装certbot,关于snapd 包管理,可以到网上查看

ubuntu 已经自带snap, 使用时只要更新命令更新 sudo snap install core; sudo snap refresh core

2. 安装 certbot

安装前先删除 原来的安装的certbot , sudo apt remove certbot

执行安装命令 sudo snap install –classic certbot

把certbot命令添加到全局 sudo ln -s /snap/bin/certbot /usr/bin/certbot

3. 获取证书 ,泛域名 要使用下面的泛域名生成方法

sudo certbot certonly –nginx

4 在nginx 配置关联证书

ssl_certificate /etc/letsencrypt/live/xxx.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/xxx.com/privkey.pem;

5. 自动更新证书

它到期之前自动更新您的证书,除非你修改配置,更新证书的配置在 /etc/letsencrypt/renewal/下面

sudo certbot renew --dry-run # 测试自动更新是否可用

The command to renew certbot is installed in one of the following locations:
/etc/crontab/
/etc/cron.*/*
systemctl list-timers

challenge 关于证书获取的简单介绍

Let’s Encrypt需要验证网站的所有权才能颁发证书, 官方称之为challenge(挑战).
在网站上的指定位置发布指定文件(HTTP-01)

当使用Webroot插件或手动插件时,请确保webroot目录存在并且您正确指定它。如果您为example.com设置了webroot目录,/var/www/example.com 那么放置的文件/var/www/example.com/.well-known/acme-challenge/testfile应该出现在您的网站上http://example.com/.well-known/acme-challenge/testfile(此处重定向到HTTPS是可以的,并且不应该阻止工作中的挑战)

sudo certbot certonly --standalone --email 'zbysir@qq.com' -d 'bysir.com'

standalone 就是独立插件, 它需要绑定80端口, 所以先关掉机器上的80端口吧, 或者换一台主机安装.
不出意外的话, 会死在Waiting for verification…,

可以看到他会请求 http://bysir.store/.well-known/acme-challenge/r9NH9hle6_7L9avkG-ID6A1BI4h4IgFVn6nx3VQZRpI以认证网站.
location ~ “^/\.well-known/acme-challenge/(.*)$” {
default_type text/plain;
return 200 “$1.IL3bE2eqHDs1k0Lmxm63CXpLvzmosMuUDIywEIBTPnG”;
}

  • 在网站上提供指定的临时证书(TLS-SNI-01)
  • 在域名系统中发布指定的DNS记录(DNS-01)

泛域名证书

certbot certonly --preferred-challenges dns --manual -d *.mydomain.com --server https://acme-v02.api.letsencrypt.org/directory

–preferred-challenges dns: 认证方式选择DNS, 泛域名支持DNS
–manual: 手动模式, 这里为了简单就使用手动认证了, 下面会说自动模式的使用.
-d *.mydomain.com: 就是要申请的泛域名了
–server https://acme-v02.api.letsencrypt.org/directory: 泛域名证书是新功能, 如果要使用就得加上这个参数

注意这一步 命令里会有提示,需要手动配置TXT记录, 在域名解析服务商添加一个泛解析就可以了, 设置好了再敲下回车.

泛域名证书docker 方法 (不推荐)

sudo docker run -it --rm --name certbot \
-v "/etc/letsencrypt:/etc/letsencrypt" \
-v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
certbot/certbot certonly -d *.mical.com --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory

根据提示 在域名供应商里添加txt 记录

dig -t txt _acme-challenge.michnal.com

再次更新

docker run -it --rm --name certbot
-v "/etc/letsencrypt:/etc/letsencrypt"
-v "/var/lib/letsencrypt:/var/lib/letsencrypt"
certbot/certbot certonly --manual -d '*.michan.cn'

泛域名证书-插件方法认证域名(推荐)

此法就不需要手动在 dns 服务器商那里 添加txt 记录了

以下用 cloudflare  dns 服务器 ,除了 第三步不一样,其他都一样

https://certbot-dns-cloudflare.readthedocs.io/en/stable/index.html#welcome-to-certbot-dns-cloudflare-s-documentation

  1. 安装dns plugin  这里要安装cloudflare 版的,
  2. 然后到cloudflare 控制台  创建 token ,设置token权限: The Token needed by Certbot requires Zone:DNS:Edit permissions for only the zones you need certificates for.
  3. 然后把token  放到自己创建 cloudfare.ini 文件里, 文件权限 chmod 600
# Cloudflare API token used by Certbot
dns_cloudflare_api_token = 0123456789abcdef0123456789abcdef01234567

下面是命令 执行

这里接安装cerbot 的第二步

sudo snap set certbot trust-plugin-with-root=ok # 确认插件包含级别

sudo snap install certbot-dns-cloudflare # 安装插件, 不同的dns 服务商,不同的插件这是是cloudflare 

sudo mkdir /home/.secrets/  
sudo chmod 700 /home/.secrets/ 
sudo vim /home/.secrets/certbot_cloudflare.ini 
# 輸入: dns_cloudflare_api_token = xxxxtokenxxx 
# 在cloudflare上開token,權限 Zone:Zone:Read, Zone:DNS:Edit for all zones 

sudo chmod 600 ~/.secrets/cloudflare.ini 
sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /home/wei/.secrets/certbot_cloudflare.ini \
  -d xmetal.cc,*.xmetal.cc

http 状态码

301适合永久重定向
301 Moved Permanently 被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。

比如,我们访问 http://www.baidu.com 会跳转到 https://www.baidu.com,发送请求之后,就会返回301状态码,然后返回一个location,提示新的地址,浏览器就会拿着这个新的地址去访问。

302用来做临时跳转
302 Found 请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。
比如未登陆的用户访问用户中心重定向到登录页面。

[cc ]
//把来自veryyoung.me的请求301跳到 www.veryyoung.me
rewrite后面接上permenent就代表301跳
接上redirect就代表302跳
if ($host != ‘veryyoung.me’) {
rewrite ^/(.*)$ http://www.veryyoung.me/$1 permanent;
}[/cc]

301重定向和302重定向的区别
  302重定向只是暂时的重定向,搜索引擎会抓取新的内容而保留旧的地址,因为服务器返回302,所以,搜索搜索引擎认为新的网址是暂时的。

  而301重定向是永久的重定向,搜索引擎在抓取新的内容的同时也将旧的网址替换为了重定向之后的网址。