关于启用 HTTPS 的一些经验分享

by admin on 2019年9月8日

关于启用 HTTPS 的一对经历分享(二)

2015/12/24 · 基本功本领 ·
HTTP,
HTTPS

原稿出处:
imququ(@屈光宇)   

小说目录

  • SSL 版本选用
  • 加密套件选用
  • SNI 扩展
  • 证件选取

几天前,一个人相爱的人问作者:都说推荐用 Qualys SSL
Labs 这一个工具测量检验 SSL
安全性,为啥有个别安全实力很强的大商家评分也比十分的低?作者感觉这些标题应当从两地点来看:1)国内顾客终端情状复杂,比非常多时候降落
SSL 安全配置是为了合作越多客户;2)确实有部分大厂家的 SSL
配置很不正规,越发是布局了有些鲜明不应该使用的 CipherSuite。

自个儿此前写的《关于启用 HTTPS
的部分经历分享(一)》,首要介绍 HTTPS
怎么样与部分新出的安全规范合营使用,面向的是当代浏览器。而明天那篇文章,更加的多的是介绍启用
HTTPS 进度中在老旧浏览器下只怕境遇的标题,以及怎么着接纳。

有关启用 HTTPS 的一部分经验分享

2015/12/04 · 基本功技艺 ·
HTTP,
HTTPS

初稿出处:
imququ(@屈光宇)   

乘势国内互连网遇到的持续恶化,种种篡改和绑架司空眼惯,越多的网址精选了全站
HTTPS。就在后日,无偿提供证书服务的 Let’s
Encrypt 项目也规范开放,HTTPS 极快就能够变成WEB 必选项。HTTPS 通过 TLS
层和证件机制提供了剧情加密、身份ID明和数据完整性三大功效,能够使得防守数据被翻开或歪曲,以及堤防中间人伪造。本文分享部分启用
HTTPS 进程中的经验,珍惜是何许与局地新出的平安标准协作使用。至于 HTTPS
的安插及优化,在此以前写过无数,本文不重复了。

背景

近年来为了扛 DDoS
攻击,从移动公司申请了一台服务器,移动集团免费提供流量洗濯效能。但由于没有备案,移动公司不容许开展
80 端口。

这是一份明天在开拓者头条上最受大家款待的上品文章列表,头条君每一天晚上为您送达,不见不散!

实质上是因为GitLab只肩负监听本地socket文件,而web服务器选取了Nginx等。只需求在web
server上做适合的布局就能够。

SSL 版本接纳

TLS(Transport Layer Security,传输层安全)的前身是 SSL(Secure Sockets
Layer,安全套接字层),它最先的多少个版本(SSL 1.0、SSL 2.0、SSL
3.0)由网景公司开销,从 3.1 先导被 IETF 标准化并改名,发展到现在已经有 TLS
1.0、TLS 1.1、TLS 1.2 多个版本。TLS 1.3 改造会相当的大,方今还在草案阶段。

SSL 1.0 从未公开过,而 SSL 2.0 和 SSL 3.0
都存在安全主题素材,不推荐使用。Nginx 从 1.9.1 最初默许只援助 TLS
的五个版本,以下是 Nginx
官方文书档案中对
ssl_protocols 配置的验证:

Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1]
[TLSv1.2];
Default: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Context: http, server
Enables the specified protocols. The TLSv1.1 and TLSv1.2 parameters
work only when the OpenSSL library of version 1.0.1 or higher is used.

但不幸的是,IE 6 只支持 SSLv2 和
SSLv3(来源),也正是说
HTTPS 网址要协理 IE 6,就必得启用 SSLv3。仅这一项就能够促成 SSL Labs
给出的评分降为 C。

理解 Mixed Content

HTTPS 网页中加载的 HTTP 资源被誉为 Mixed
Content(混合内容),不相同浏览器对 Mixed Content 有不均等的拍卖法规。

目标

为了尽早启用那台负担着负载均衡和反向代理(其实未有负载均衡)的服务器,作者安插接纳https 合同,利用 443 端口进而避开 80
端口为客商提供正规服务。同有时候经过应用 https 左券,使得网址访谈进一步安全。

前日最棒 Top 3:

下边是贰个采纳Nginx的例子,对GitLab安装指南下载的gitlab脚本文件做了稳当的修改。

加密套件选拔

加密套件(CipherSuite),是在 SSL
握手中必要交涉的很要紧的一个参数。顾客端会在 Client Hello
中带上它所帮忙的 CipherSuite 列表,服务端会从中选定二个并经过
Server Hello 重返。假若顾客端帮助的 CipherSuite 列表与服务端配置的
CipherSuite 列表未有交集,会促成不可能成功商业事务,握手失败。

CipherSuite
满含各个技术,举个例子认证算法(Authentication)、加密算法(Encryption)、信息认证码算法(Message
Authentication Code,简称为 MAC)、密钥沟通算法(Key
Exchange)和密钥衍生算法(Key Derivation Function)。

SSL 的 CipherSuite 协商业机械制具有可以的扩充性,各样 CipherSuite 都亟待在
IANA 注册,并被分配八个字节的标记。全部 CipherSuite 能够在 IANA 的 TLS
Cipher Suite
Registry
页面查看。

OpenSSL 库支持的整整 CipherSuite 能够经过以下命令查看:

openssl ciphers -V | column -t 0xCC,0x14 – ECDHE-ECDSA-CHACHA20-POLY1305
TLSv1.2 Kx=ECDH Au=ECDSA Enc=ChaCha20-Poly1305 Mac=AEAD … …

1
2
3
openssl ciphers -V | column -t
0xCC,0x14  –  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH        Au=ECDSA   Enc=ChaCha20-Poly1305  Mac=AEAD
… …

0xCC,0x14 是 CipherSuite 的号码,在 SSL
握手中会用到。ECDHE-ECDSA-CHACHA20-POLY1305
是它的名目,之后几局地各自表示:用于 TLSv1.2,使用 ECDH 做密钥沟通,使用
ECDSA 做注解,使用 ChaCha20-Poly1305 做对称加密,由于 ChaCha20-Poly1305
是一种 AEAD 形式,无需 MAC 算法,所以 MAC 列显示为 AEAD。

要打听 CipherSuite 的越多内容,能够阅读这篇长文《TLS 商讨解析 与
现代加密通讯左券设计》。由此可见,在配备
CipherSuite 时,请必得参照他事他说加以考察权威文书档案,如:Mozilla
的推荐介绍配置、CloudFlare
使用的配置。

以上 Mozilla 文档中的「Old backward compatibility」配置,以及 CloudFlare
的布局,都得以很好的非凡老旧浏览器,包括 Windows XP / IE6。

从前看来有个别大厂家乃至扶助满含 EXPORT
CipherSuite,那么些套件在上世纪由于米利坚开口限制而被减弱过,已被夺回,实在未有理由再采用。

早期的 IE

最先的 IE 在发掘 Mixed Content
央浼时,会弹出「是或不是只查看安全传送的网页内容?」这样二个模态对话框,一旦顾客挑选「是」,所有Mixed Content 财富都不会加载;采取「否」,全数能源都加载。

步骤

1.什么免费地让网站启用
HTTPS

# GITLAB
# Maintainer: @randx
# App Version: 4.0

SNI 扩展

我们驾驭,在 Nginx 中能够透过点名不相同的 server_name
来配置多个站点。HTTP/1.1 协议恳求头中的 Host
字段能够标识出当下呼吁属于哪个站点。然而对于 HTTPS 网址来讲,要想发送
HTTP 数据,必得等待 SSL
握手完结,而在拉手阶段服务端就亟须提供网址证书。对于在同贰个 IP 安插不一样HTTPS 站点,並且还动用了分化证书的情况下,服务端怎么了解该发送哪个证书?

Server Name Indication,简称为 SNI,是 TLS
的贰个扩大,为化解那几个标题出现。有了 SNI,服务端能够因此
Client Hello 中的 SNI 扩大得到客商要探望网址的 Server
Name,从而发送与之协作的注解,顺遂完毕 SSL 握手。

Nginx 在很早从前就支持了 SNI,能够由此 nginx -V
来验证。以下是本身的求证结果:

./nginx -V nginx version: nginx/1.9.9 built by gcc 4.8.4 (Ubuntu
4.8.4-2ubuntu1~14.04) built with OpenSSL 1.0.2e-dev xx XXX xxxx TLS SNI
support enabled configure arguments: –with-openssl=../openssl
–with-http_ssl_module –with-http_v2_module

1
2
3
4
5
6
./nginx -V
nginx version: nginx/1.9.9
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
built with OpenSSL 1.0.2e-dev xx XXX xxxx
TLS SNI support enabled
configure arguments: –with-openssl=../openssl –with-http_ssl_module –with-http_v2_module

只是,并非全数浏览器都援助 SNI,以下是广大浏览器帮衬 SNI 的最低版本:

浏览器 最低版本
Chrome Vista+ 全支持;XP 需要 Chrome 6+;OSX 10.5.7+ 且 Chrome 5+
Firefox 2.0+
Internet Explorer 7+ (需要 Vista+)
Safari 3+ (需要 OS X 10.5.6+)
Mobile Safari iOS 4.0+
Android Webview 3.0+

若是要防止在不协理 SNI 的浏览器中冒出证书错误,只可以将利用分化证书的
HTTPS 站点布局在分化 IP 上,最简便的做法是分开陈设到不一样机器上。

正如新的 IE

相比较新的 IE
将模态对话框改为页面底部的提醒条,未有事先那么苦恼客户。并且暗许会加载图片类
Mixed Content,另外如 JavaScript、CSS
等能源如故会基于客户挑选来调整是不是加载。

选料证书颁发机构

有过多证件颁发机构,在此以前也应用过 StartSSL
的注解,但新兴被中华夏族民共和国的市肆收购了,由此一贯铲除。当前不收费又火的证件颁发机构当属
Let’s encrypt 了,因而本次作者也利用该单位的证书。

2.有赞风控准则引擎施行

upstream gitlab {
  server unix:/home/gitlab/gitlab/tmp/sockets/gitlab.socket;
}

证件采纳

HTTPS 网址需求通过 CA
获得合法证件,证书通过数字签字本领保险第三方无法伪造。证书的简易原理如下:

  • 故事版本号、类别号、签名算法标记、发行者名称、保藏期、证书主体名、证书主体公钥音讯、发行商独一标志、主体独一标记、扩大生成
    TBSCertificate(To Be Signed Certificate, 待具名证书)音信;
  • 签发数字具名:使用 HASH 函数对 TBSCertificate 总计获得音讯摘要,用
    CA 的私钥对音信摘要举行加密,获得具名;
  • 校验数字具名:使用同样的 HASH 函数对 TBSCertificate
    总结获得新闻摘要,与应用 CA 公钥解密签名获得内容相相比较;

利用 SHA-1 做为 HASH 函数的证书被叫做 SHA-1 证书,由于当下早就找到
SHA-1 的磕碰标准,将证件换到选取更安全的 SHA-2 做为 HASH 函数的 SHA-2
证书被提上日程。

实则,微软现已宣称自 2017 年 1 月 1 日起,将完美终止对 SHA-1
证书的支撑。届时在新型版本的 Windows 系统中,SHA-1 证书将不被信任。

而据说 Chrome
官方博客的文章,使用
SHA-1 证书且证书保藏期在 二零一四 年 1 月 1 号至 二零一六 年 12 月 31
号之间的站点会被予以「安全的,但存在破绽」的提拔,也正是地址栏的小锁不再是石黄的,并且会有贰个色情小三角。而选用SHA-1 证书且证书保藏期超越 2017 年 1 月 1
号的站点会被给予「不安全」的革命警戒,小锁上一贯展现三个莲红的叉。

唯独,实际不是有所的极端都扶助 SHA-2
证书,服务端不补助还好办,浏览器只好信赖于客商晋级了。下边是大面积浏览器援助SHA-2 证书的最低版本:

浏览器 支持 SHA-2 证书的最低版本
Chrome 26+
Firefox 1.5+
Internet Explorer 6+ (需要 XP SP3+)
Safari 3+ (需要 OS X 10.5+)
Android Webview 2.3+

能够看看,假若要照望未有打 XP SP3 补丁的 IE6 客商,只能继续使用 SHA-1
证书。

在自己前面包车型的士篇章中,还涉嫌过 ECC
证书,这种新型的证件辅助度更差,这里略过不提,有意思味的同室能够点这里查看。

是还是不是足以本着不相同浏览器启用分裂证书吗?理论上服务端能够依赖顾客端
Client Hello 中的 Cipher Suites 特征以及是还是不是扶助 SNI
的特点来分配分歧证书,可是自身尚未实际验证过。

本文先写那样多,比较多安顿都亟待基于自身网站的客商来支配,比如我的博客基本没有IE8- 客商,理之当然能够禁止使用SSLv3。假若你的成品还会有众多行使老旧浏览器的顾客,那就必得为那几个客商做合营方案了。一种方案是:只把主域安全等第配低,将
XP 上 IE 客户的 HTTPS 央浼直接重定向到 HTTP
版本,那样任何域名可以选取高安全品级的布局,运行起来相比有利。

1 赞 1 收藏
评论

图片 1

今世浏览器

当代浏览器(Chrome、Firefox、Safari、Microsoft Edge),基本上都遵守了
W3C 的 Mixed Content 规范,将
Mixed Content 分为Optionally-blockable 和 Blockable 两类:

Optionally-blockable 类 Mixed Content
满含那一个危险比较小,即便被中间人歪曲也无大碍的能源。今世浏览器暗中认可会加载那类能源,同期会在调节台打字与印刷警告消息。那类能源包罗:

  • 通过 <img> 标签加载的图样(包含 SVG 图片);
  • 通过 <video> / <audio> 和 <source> 标签加载的摄像或音频;
  • 预读的(Prefetched)资源;

除此而外全数的 Mixed Content
都是 Blockable,浏览器务必禁止加载那类财富。所以今世浏览器中,对于
HTTPS 页面中的 JavaScript、CSS 等 HTTP
财富,一律不加载,直接在调整台打字与印刷错误信息。

安装符合规律的访谈法规和平安准绳

  1. 设置应用服务器;
  2. 设置反向代理服务器;
  3. 安装域名分析;

3.[译]
JavaScript 专门的学问机制:V8 引擎内部机制及怎么着编写优化代码的 5
个门槛

server {
  listen 443;
  ssl                  on;
  ssl_certificate      /etc/nginx/sites-available/server.crt;
  ssl_certificate_key  /etc/nginx/sites-available/server.key;

运动浏览器

日前所说都是桌面浏览器的一颦一笑,移动端情状相比复杂,当前相当多移动浏览器私下认可都同意加载
Mixed Content。也正是说,对于运动浏览器来讲,HTTPS 中的 HTTP
财富,无论是图片依然 JavaScript、CSS,暗中同意都会加载。

相似选拔了全站 HTTPS,就要避免出现 Mixed Content,页面全体财富央浼都走
HTTPS 协议才干确认保障具有平台具备浏览器下都尚未难题。

安装应用服务器

  • 将享有应用都布署好;
  • 透过 PM2 合併的布置文件运转具有应用;
  • 应用服务器防火墙开放 8000 ~ 8999 区间的端口;
  • 安装安全组。入方向只允许持有 IP 地址访谈 22 的 TCP
    端口,以及反向代理服务器的 IP 地址访问 八千 ~ 8999 的 TCP
    端口;出方向允许全数端口和商业事务;

50 万程序员都在用的 App,扫描下方二维码,立即体验!

  server_name localhost;
  #Ubuntu1204-dell
source.cml.com;    # e.g., server_name source.example.com;
  root /home/gitlab/gitlab/public;

合理利用 CSP

CSP,全称是 Content Security
Policy,它有比非常多的一声令下,用来兑现美妙绝伦与页面内容安全皮之不存毛将焉附的功用。这里只介绍多少个与
HTTPS 相关的指令,更加多内容能够看自己事先写的《Content Security Policy
Level 2
介绍》。

设置反向代理服务器

  • 在反向代理服务器上安顿全数应用服务器应用的域名分析;

图片 2

 

block-all-mixed-content

后边说过,对于 HTTPS 中的图片等 Optionally-blockable 类 HTTP
财富,当代浏览器暗许会加载。图片类财富被威逼,常常不会有太大的标题,但也许有一点高危害,比如相当多网页按键是用图形完成的,中间人把这么些图片改掉,也会震惊客户使用。

通过 CSP
的 block-all-mixed-content 指令,可以让页面步向对混合内容的严格检查测验(Strict
Mixed Content Checking)情势。在这种格局下,全数非 HTTPS
能源都分歧意加载。跟任何具备 CSP
法则同样,能够透过以下两种艺术启用这些命令:

HTTP 响应头格局:

JavaScript

Content-Security-Policy: block-all-mixed-content

1
Content-Security-Policy: block-all-mixed-content

<meta> 标签格局:

XHTML

<meta http-equiv=”Content-Security-Policy”
content=”block-all-mixed-content”>

1
<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

设置域名分析

  • 将装有域名分析都对准反向代理服务器的 IP 地址;

50 万程序猿都在用的 App

  # individual nginx logs for this gitlab vhost
  access_log  /var/log/nginx/gitlab_access.log;
  error_log  /var/log/nginx/gitlab_error.log;

upgrade-insecure-requests

历史长久的大站在往 HTTPS
迁移的经过中,专门的学业量往往非常伟大,极度是将有着财富都替换为 HTTPS
这一步,很轻松生出疏漏。就算拥有代码都认账没非凡,很恐怕有些从数据库读取的字段中还留存
HTTP 链接。

而通过 upgrade-insecure-requests 那几个 CSP
指令,能够让浏览器帮助做那个调换。启用那么些计策后,有多少个调换:

  • 页面全数 HTTP 能源,会被沟通为 HTTPS 地址再发起呼吁;
  • 页面全体站内链接,点击后会被交换为 HTTPS 地址再跳转;

跟任何具备 CSP
法则平等,那一个命令也是有三种艺术来启用,具体魄式请参照他事他说加以考察上一节。要求潜心的是 upgrade-insecure-requests 只替换公约部分,所以只适用于
HTTP/HTTPS 域名和路子完全一致的场合。

配置 https 协议

  location / {
    # serve static files from defined root folder;.
    # @gitlab is a named location for the upstream fallback, see
below
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

成立运用 HSTS

在网址全站 HTTPS 后,假若客户手动敲入网址的 HTTP
地址,恐怕从任什么地方方点击了网址的 HTTP 链接,重视于服务端 30一半02
跳转才能使用 HTTPS 服务。而首先次的 HTTP
诉求就有非常大可能率被威吓,导致诉求十分的小概到达服务器,从而结成 HTTPS 降级威迫。

参谋资料

  # if a file, which is not found in the root folder is requested,
  # then the proxy pass the request to the upsteam (gitlab unicorn)
  location @gitlab {
    proxy_read_timeout 300; #

    proxy_connect_timeout 300; #

    proxy_redirect    off;

HSTS 基本使用

以此标题得以因此 HSTS(HTTP Strict Transport
Security,RFC6797)来化解。HSTS
是三个响应头,格式如下:

JavaScript

Strict-Transport-Security: max-age=expireTime [; includeSubDomains]
[; preload]

1
Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

max-age,单位是秒,用来告诉浏览器在指按期期内,那几个网址必需经过 HTTPS
左券来做客。也即是对于那么些网址的 HTTP 地址,浏览器需要先在本地替换为
HTTPS 之后再发送须要。

includeSubDomains,可选参数,假若内定这一个参数,注明这么些网址有着子域名也必得经过
HTTPS 左券来拜会。

preload,可选参数,前边再介绍它的效果与利益。

HSTS 这么些响应头只可以用来 HTTPS 响应;网址必需使用私下认可的 443
端口;必需利用域名,不可能是 IP。并且启用 HSTS
之后,一旦网址证书错误,顾客不可能取舍忽略。

    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  Host              $http_host;
    proxy_set_header  X-Real-IP        $remote_addr;

HSTS Preload List

能够见到 HSTS 可以很好的化解 HTTPS 降级攻击,可是对于 HSTS 生效前的首次HTTP 央浼,依然无能为力幸免被威迫。浏览器商家们为了消除那几个主题素材,建议了 HSTS
Preload List
方案:内置一份列表,对于列表中的域名,即便客商此前从没访问过,也会使用
HTTPS 协议;列表能够按时更新。

现阶段那个 Preload List 由 谷歌(Google) Chrome 维护,Chrome、Firefox、Safari、IE
11 和 Microsoft Edge
都在动用。如若要想把温馨的域名加进这几个列表,首先需求满足以下标准:

  • 全体合法的评释(假使运用 SHA-1 证书,过期时光必须早于 2014 年);
  • 将具有 HTTP 流量重定向到 HTTPS;
  • 确定保障全体子域名都启用了 HTTPS;
  • 输出 HSTS 响应头:
    • max-age 不可能低于 18 周(10886400 秒);
    • 不能够不钦赐 includeSubdomains 参数;
    • 必得钦命 preload 参数;

就算知足了上述全部条件,也不必然能步入 HSTS Preload
List,更加多消息能够看这里。通过
Chrome 的 chrome://net-internals/#hsts工具,能够查询某些网址是还是不是在
Preload List 之中,还可以够手动把某些域名加到本机 Preload List。

对此 HSTS 以及 HSTS Preload List,作者的提出是如若你无法担保永世提供 HTTPS
服务,就毫无启用。因为如若 HSTS 生效,你再想把网站重定向为
HTTP,在此之前的老客户会被Infiniti重定向,独一的措施是换新域名。

    proxy_pass ;
  }
}

CDN 安全

对于大站来讲,全站迁移到 HTTPS 后要么得用 CDN,只是必需挑选帮助 HTTPS 的
CDN 了。假若应用第三方 CDN,安全地方有一部分亟需思虑的地方。

专心 server { 上边包车型地铁四行。

客观运用 SRAV4I

HTTPS
能够免卫数据在传输中被曲解,合法的证书也能够起到表达服务器身份的机能,可是只要
CDN 服务器被侵犯,导致静态文件在服务器上被曲解,HTTPS 也敬谢不敏。

W3C 的 SRI(Subresource
Integrity)标准能够用来消除那么些难题。SHavalI
通过在页面引用能源时钦命能源的摘要签字,来落到实处让浏览器验证能源是还是不是被歪曲的目标。只要页面不被曲解,S昂科拉I
战术就是保障的。

关于 SKugaI 的越来越多表达请看自个儿事先写的《Subresource Integrity
介绍》。S安德拉I 并非HTTPS
专项使用,但即使主页面被威迫,攻击者能够轻松去掉能源摘要,进而失去浏览器的
S智跑I 校验机制。

监听443端口,启用ssl,server.crt和server.key文件是参谋Nginx的文书档案生成的。

了解 Keyless SSL

除此以外三个难点是,在运用第三方 CDN 的 HTTPS
服务时,如果要利用自身的域名,须求把相应的证件私钥给第三方,那也是一件高危机非常高的政工。

CloudFlare 公司针对这种光景研究开发了 Keyless SSL
技巧。你能够不把证件私钥给第三方,改为提供一台实时总计的 Key Server
就能够。CDN 要用到私钥时,通过加密大道将要求的参数字传送给 Key Server,由 Key
Server 算出结果并回到就能够。整个进度中,私钥都保证在友好的 Key Server
之中,不会揭发给第三方。

CloudFlare
的那套机制已经开源,如需明白详细情况,能够查看他们官方博客的那篇作品:Keyless
SSL: The Nitty Gritty Technical
Details。

好了,本文先就写到这里,须求小心的是本文提到的 CSP、HSTS 以及 S陆风X8I
等宗旨都独有新型的浏览器才支撑,详细的支撑度能够去CanIUse 查。切换成HTTPS
之后,在性质优化上有非常多新职业要做,这一部分剧情笔者在事先的博客中写过相当多,这里不再另行,只说最要紧的一些:既然都
HTTPS 了,赶紧上 HTTP/2 才是正道。

1 赞 4 收藏
评论

图片 1

最后proxy_pass 不能够修改,不要改成https,不然不可能干活。

后天试一下用https的法子check out 代码:

git clone https://….

报错,说证书校验有标题:

error: server certificate verification failed. CAfile:
/etc/ssl/certs/ca-certificates.crt CRLfile: none

最简便易行的消除格局是加五个境况变量:

export GIT_SSL_NO_VERIFY=1

GitLab
的详尽介绍
:请点这里
GitLab
的下载地址
:请点这里

图片 4

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图