标签 证书 下的文章

当涉及到 SSL/TLS 证书时,你可能会遇到各种问题,有些与浏览器有关,有些则是网站后台的问题。

其中一个错误是 Linux 中的 “Unacceptable TLS certificate”。

不幸的是,对此没有“一劳永逸”的答案。然而,有一些潜在的解决方案,你可以尝试,在此,我打算为你强调这些。

你什么时候会遇到这个 TLS 证书问题?

在我的例子中,我是在通过终端添加 Flathub 仓库时注意到这个问题的,这个步骤可以让你在 设置 Flatpak 时访问大量的 Flatpak 集合。

然而,在安装 Flatpak 应用或通过终端使用来自第三方仓库的 Flatpak 参考文件时,你也可能会遇到这个错误。

一些用户在 Linux 上使用他们组织推荐的 VPN 服务工作时注意到这个问题。

那么,如何解决这个问题呢?为什么这是一个问题?

嗯,从技术上讲,这是两件事中的一个:

  • 你的系统不接受该证书(并说它是无效的)。
  • 该证书与用户连接的域不匹配。

如果是第二种情况,你得联系网站的管理员,从他们那里解决这个问题。

但是,如果是第一种情况,你有几种方法来处理它。

1、在使用 Flatpak 或添加 GNOME 在线账户时修复 “Unacceptable TLS certificate”

如果你试图添加 Flathub 远程或一个新的 Flatpak 应用,并在终端中注意到这个错误,你可以简单地输入:

sudo apt install --reinstall ca-certificates

这应该会重新安装受信任的 CA 证书,以防止列表中出现某种问题。

在我的例子中,当试图添加 Flathub 仓库时,我遇到了错误,通过在终端输入上述命令解决了这个问题。

所以,我认为任何与 Flatpak 有关的 TLS 证书问题都可以用这个方法解决。

2、在使用工作 VPN 时修复 “Unacceptable TLS certificate”

如果你使用你的组织的 VPN 来访问与工作有关的材料,你可能要把证书添加到你的 Linux 发行版中的可信 CA 列表中。

请注意,你需要 VPN 服务或你组织的管理员分享根证书的 .CRT 版本,才能开始使用。

接下来,你需要进入 /usr/local/share/ca-certificates 目录。

你可以下面创建一个目录,并使用任何名称来标识你组织的证书。然后,将 .CRT 文件添加到该目录。

例如,它是 /usr/local/share/ca-certificates/organization/xyz.crt

请注意,你需要有 root 权限来添加证书或在 ca-certificates 目录下创建目录。

当你添加了必要的证书,你所要做的就是输入以下命令更新证书支持列表:

sudo update-ca-certificates

而且,每当你试图连接到你公司的 VPN 时,你的系统应将该证书视为有效。

总结

不可接受的 TLS 证书并不是一个常见的错误,但你可以在各种使用情况下发现它,比如连接到 GNOME 在线账户。

如果上述两种方法都不能解决这个错误,那么你所连接的域/服务有可能存在配置错误。在这种情况下,你将不得不联系他们来解决这个问题。

你是否遇到过这个错误?你是如何解决的?你是否知道这个问题的其他解决方案(有可能是容易操作的)?请在下面的评论中告诉我你的想法。


via: https://itsfoss.com/unacceptable-tls-certificate-error-linux/

作者:Ankush Das 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

介绍

OpenSSL 是一个多功能的命令行工具,可以用于与 公钥基础设施 Public Key Infrastructure (PKI)和 HTTPS(HTTP over TLS)相关的大量任务。这本小抄风格的指南提供了 OpenSSL 命令的快速参考,这些命令在常见的日常场景中非常有用。这包括生成私钥、 证书签署请求 certificate signing request (CSR)和证书格式转换的 OpenSSL 示例,但它并没有涵盖 OpenSSL 的所有用途。

如何使用本指南

  • 如果你不熟悉证书签署请求(CSR),请阅读第一部分。
  • 除了第一部分,本指南采用了简单的小抄格式:自带了命令行代码片段。
  • 跳到与你准备完成的任务相关的任何部分。
  • 大多数命令都是单行的,为了清晰起见,已经扩展到多行(使用 \ 符号)。

关于证书签署请求(CSR)

如果你想从 证书颁发机构 certificate authority (CA)那里获得 SSL 证书,你必须生成一个 证书签署请求 certificate signing request (CSR)。一个 CSR 主要是由一个密钥对的公钥和一些附加信息组成。当证书被签署时,这两部分都会被插入到证书中。

每当你生成一个 CSR 时,你会被提示提供有关证书的信息。这些信息被称为 区分名称 Distinguised Name (DN)。DN 中的一个重要字段是 通用名称 Common Name (CN),它应该是你打算使用证书的主机的 完全合格域名 Fully Qualified Domain Name (FQDN)。当创建 CSR 时,也可以通过命令行或文件传递信息来跳过交互式提示。

DN 中的其他项目提供了有关你的业务或组织的附加信息。如果你是从证书机构购买 SSL 证书,通常要求这些附加字段(如“ 组织 Organization ”)准确地反映你的组织的详细信息。

下面是一个 CSR 信息提示的例子:

---
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:Brooklyn
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Brooklyn Company
Organizational Unit Name (eg, section) []:Technology Division
Common Name (e.g. server FQDN or YOUR name) []:examplebrooklyn.com
Email Address []:

如果你想非交互式地回答 CSR 信息提示,你可以通过在任何请求 CSR 信息的 OpenSSL 命令中添加 -subj 选项来实现。这里是该选项的一个例子,使用上面代码块中显示的相同信息:

-subj "/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=examplebrooklyn.com"

现在你已经了解了 CSR,可以自由跳转到本指南中涵盖你的 OpenSSL 需求的任何一节。

生成 CSR

本节介绍了与生成 CSR(以及私钥,如果它们还不存在的话)有关的 OpenSSL 命令。CSR 可以用来向证书颁发机构请求 SSL 证书。

请记住,你可以通过上一节中提到的 -subj 选项非交互式地添加 CSR 信息。

生成一个私钥和一个 CSR

如果你想使用 HTTPS(HTTP over TLS)来保护你的 Apache HTTP 或 Nginx Web 服务器的安全,并且你想使用一个证书颁发机构(CA)来颁发 SSL 证书,那么就使用这个方法。生成的 CSR 可以发送给 CA,请求签发由 CA 签名的 SSL 证书。如果你的 CA 支持 SHA-2,请添加 -sha256 选项,用 SHA-2 签署 CSR。

这条命令从头开始创建一个 2048 位的私钥(domain.key)和一个 CSR(domain.csr):

openssl req \
       -newkey rsa:2048 -nodes -keyout domain.key \
       -out domain.csr

回答 CSR 信息提问,完成该过程。

选项 -newkey rsa:2048 指定密钥应该是 2048 位,使用 RSA 算法生成。选项 -nodes 指定私钥没有用密码加密。这里没有包含 -new 选项,而是隐含在其中,表示正在生成一个 CSR。

从现有的私钥中生成一个 CSR

如果你已经有了私钥,并想用它向 CA 申请证书,请使用这个方法。

该命令基于现有的私钥(domain.key)创建一个新的 CSR(domain.csr):

openssl req \
       -key domain.key \
       -new -out domain.csr

回答 CSR 信息提问,完成该过程。

选项 -key 指定一个现有的私钥(domain.key),它将被用来生成一个新的 CSR。选项 -new 表示正在生成一个 CSR。

从现有的证书和私钥生成 CSR

如果你想更新现有的证书,但由于某些原因,你或你的 CA 没有原始的 CSR,请使用这个方法。基本上可以省去重新输入 CSR 信息的麻烦,因为它是从现有证书中提取信息的。

该命令基于现有的证书(domain.crt)和私钥(domain.key)创建一个新的 CSR(domain.csr):

openssl x509 \
       -in domain.crt \
       -signkey domain.key \
       -x509toreq -out domain.csr

选项 -x509toreq 指定你使用一个 X509 证书来制作 CSR。

生成 SSL 证书

如果你想使用 SSL 证书来确保服务的安全,但你不需要 CA 签名的证书,一个有效的(和免费的)解决方案是签署你自己的证书。

你可以自己签发的一种常见证书是 自签证书 self-signed certificate 。自签证书是用自己的私钥签署的证书。自签证书和 CA 签名证书一样可以用来加密数据,但是你的用户会显示一个警告,说这个证书不被他们的计算机或浏览器信任。因此,只有当你不需要向用户证明你的服务身份时,才可以使用自签名证书(例如非生产或非公开服务器)。

本节介绍与生成自签名证书相关的 OpenSSL 命令。

生成自签证书

如果你想使用 HTTPS(HTTP over TLS)来保护你的 Apache HTTP 或 Nginx Web 服务器,并且你不需要你的证书由 CA 签名,那么就使用这个方法。

这个命令可以从头开始创建一个 2048 位的私钥(domain.key)和一个自签证书(domain.crt):

openssl req \
       -newkey rsa:2048 -nodes -keyout domain.key \
       -x509 -days 365 -out domain.crt

回答 CSR 信息提问,完成该过程。

选项 -x509 告诉 req 子命令创建一个自签名的证书。-days 365 选项指定证书的有效期为 365 天。它会生成一个临时的 CSR,以收集与证书相关的信息。

从现有私钥生成自签名证书

如果你已经有了一个私钥,并且你想用它来生成一个自签证书,请使用这个方法。

这条命令可以从现有的私钥(domain.key)中创建一个自签证书(domain.crt):

openssl req \
       -key domain.key \
       -new \
       -x509 -days 365 -out domain.crt

回答 CSR 信息提问,完成该过程。

选项 -x509 告诉 req 子命令创建一个自签证书。-days 365 选项指定证书的有效期为 365 天。选项 -new 启用 CSR 信息提问。

从现有的私钥和 CSR 生成自签证书

如果你已经有了私钥和 CSR,并且你想用它们生成一个自签证书,请使用这个方法。

这条命令将从现有的私钥(domain.key)和(domain.csr)中创建一个自签证书(domain.crt)。

openssl x509 \
       -signkey domain.key \
       -in domain.csr \
       -req -days 365 -out domain.crt

选项 -days 365 指定证书的有效期为 365 天。

查看证书

证书和 CSR 文件是以 PEM 格式编码的,不适合被人读取。

本节介绍的 OpenSSL 命令将输出 PEM 编码文件的实际条目。

查看 CSR 条目

该命令允许你查看和验证纯文本的 CSR(domain.csr)的内容:

openssl req \  
       -text -noout -verify \  
       -in domain.csr

查看证书条目

该命令允许你查看纯文本证书(domain.crt)的内容:

openssl x509 \  
       -text -noout \  
       -in domain.crt

验证证书由 CA 签署

使用此命令验证证书(domain.crt)是否由特定的 CA 证书(ca.crt)签署:

openssl verify \  
       -verbose -CAFile ca.crt \  
       domain.crt

私钥

本节介绍了用于创建和验证私钥的 OpenSSL 命令。

创建私钥

使用该命令创建一个受密码保护的 2048 位私钥(domain.key):

openssl genrsa \  
       -des3 -out domain.key 2048

在提示时输入密码以完成该过程。

验证私钥

使用此命令检查私钥(domain.key)是否为有效密钥:

openssl rsa \  
       -check -in domain.key

如果你的私钥已经加密,系统会提示你输入它的密码,成功后,未加密的密钥会在终端上输出。

验证私钥是否与证书和 CSR 匹配

使用这些命令来验证私钥(domain.key)是否匹配证书(domain.crt)和 CSR(domain.csr):

openssl rsa  -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5
openssl req  -noout -modulus -in domain.csr | openssl md5

如果每条命令的输出都是相同的,那么私钥、证书和 CSR 就极有可能是相关的。

加密私钥

这需要一个未加密的私钥(unencrypted.key),并输出它的加密版本(encrypted.key):

openssl rsa -des3 \
       -in unencrypted.key \
       -out encrypted.key

输入你所需的密码,以加密私钥。

解密私钥

这需要一个加密的私钥(encrypted.key),并输出一个解密的版本(decrypted.key):

openssl rsa \
       -in encrypted.key \
       -out decrypted.key

在提示时,输入加密密钥的密码。

转换证书格式

我们一直在使用的所有证书都是 ASCII 码 PEM 编码的 X.509 证书。还有很多其他的证书编码和容器类型;一些应用程序喜欢某些格式而不是其他格式。此外,这些格式中的许多格式可以在一个文件中包含多个项目,如私钥、证书和 CA 证书。

OpenSSL 可以用来将证书在则西格式间转换。本节将介绍一些可能的转换。

将 PEM 转换为 DER

如果要将 PEM 编码的证书(domain.crt)转换为 DER 编码的证书(domain.der),即二进制格式,请使用此命令:

openssl x509 \
       -in domain.crt \
       -outform der -out domain.der

DER 格式通常与 Java 一起使用。

将 DER 转换为 PEM

如果要将 DER 编码的证书(domain.der)转换为 PEM 编码的证书(domain.crt),请使用此命令:

openssl x509 \
       -inform der -in domain.der \
       -out domain.crt

将 PEM 转换为 PKCS7

如果你想把 PEM 证书(domain.crtca-chain.crt)添加到 PKCS7 文件(domain.p7b)中,请使用该命令:

openssl crl2pkcs7 -nocrl \
       -certfile domain.crt \
       -certfile ca-chain.crt \
       -out domain.p7b

请注意,你可以使用一个或多个 -certfile 选项来指定要添加到 PKCS7 文件中的证书。

PKCS7 文件,也被称为 P7B,通常用于 Java Keystores 和 Microsoft IIS(Windows)。它们是 ASCII 文件,可以包含证书和 CA 证书。

将 PKCS7 转换为 PEM

如果你想将 PKCS7 文件(domain.p7b)转换为 PEM 文件,请使用该命令:

openssl pkcs7 \
       -in domain.p7b \
       -print_certs -out domain.crt

请注意,如果你的 PKCS7 文件中有多个项目(如证书和 CA 中间证书),创建的 PEM 文件将包含其中的所有项目。

将 PEM 转换为 PKCS12

如果你想使用私钥(domain.key)和证书(domain.crt),并将它们组合成一个 PKCS12 文件(domain.pfx),请使用这个命令:

openssl pkcs12 \
       -inkey domain.key \
       -in domain.crt \
       -export -out domain.pfx

系统会提示你输入导出密码,你可以留空。请注意,在这种情况下,你可以通过将多个证书连接到一个 PEM 文件(domain.crt)中来添加一个证书链到 PKCS12 文件中。

PKCS12 文件,也被称为 PFX 文件,通常用于在 Micrsoft IIS(Windows)中导入和导出证书链。

将 PKCS12 转换为 PEM

如果你想转换 PKCS12 文件(domain.pfx)并将其转换为 PEM 格式(domain.combined.crt),请使用此命令:

openssl pkcs12 \
       -in domain.pfx \
       -nodes -out domain.combined.crt

请注意,如果你的 PKCS12 文件中有多个项目(如证书和私钥),创建的 PEM 文件将包含其中的所有项目。

OpenSSL 版本

openssl version 命令可以用来检查你正在运行的版本。你正在运行的 OpenSSL 版本,以及编译时使用的选项会影响到你可以使用的功能(有时也会影响到命令行选项)。

下面的命令显示了你正在运行的 OpenSSL 版本,以及它被编译时的所有选项:

openssl version -a

本指南是使用具有如下细节的 OpenSSL 二进制文件编写的(参见前面命令的输出):

OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Apr  7 21:22:23 UTC 2014
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

总结

这应该涵盖了大多数人如何使用 OpenSSL 来处理 SSL 证书的情况!它还有很多其他的用途,在这里没有介绍,所以请在评论中随时询问或建议其他用途。

如果你在使用这些命令时遇到了问题,请一定要评论(并附上你的 OpenSSL 版本输出)。


via: https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs

作者:Mitchell Anicas 选题:wxy 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

为你的微服务架构或者集成测试创建一个简单的内部 CA。

传输层安全(TLS)模型(有时也称它的旧名称 SSL)基于 证书颁发机构 certificate authoritie (CA)的概念。这些机构受到浏览器和操作系统的信任,从而签名服务器的的证书以用于验证其所有权。

但是,对于内部网络,微服务架构或集成测试,有时候本地 CA更有用:一个只在内部受信任的 CA,然后签名本地服务器的证书。

这对集成测试特别有意义。获取证书可能会带来负担,因为这会占用服务器几分钟。但是在代码中使用“忽略证书”可能会被引入到生产环境,从而导致安全灾难。

CA 证书与常规服务器证书没有太大区别。重要的是它被本地代码信任。例如,在 Python requests 库中,可以通过将 REQUESTS_CA_BUNDLE 变量设置为包含此证书的目录来完成。

在为集成测试创建证书的例子中,不需要长期的证书:如果你的集成测试需要超过一天,那么你应该已经测试失败了。

因此,计算昨天明天作为有效期间隔:

>>> import datetime
>>> one_day = datetime.timedelta(days=1)
>>> today = datetime.date.today()
>>> yesterday = today - one_day
>>> tomorrow = today - one_day

现在你已准备好创建一个简单的 CA 证书。你需要生成私钥,创建公钥,设置 CA 的“参数”,然后自签名证书:CA 证书总是自签名的。最后,导出证书文件以及私钥文件。

from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import hashes, serialization
from cryptography import x509
from cryptography.x509.oid import NameOID


private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048,
    backend=default_backend()
)
public_key = private_key.public_key()
builder = x509.CertificateBuilder()
builder = builder.subject_name(x509.Name([
    x509.NameAttribute(NameOID.COMMON_NAME, 'Simple Test CA'),
]))
builder = builder.issuer_name(x509.Name([
    x509.NameAttribute(NameOID.COMMON_NAME, 'Simple Test CA'),
]))
builder = builder.not_valid_before(yesterday)
builder = builder.not_valid_after(tomorrow)
builder = builder.serial_number(x509.random_serial_number())
builder = builder.public_key(public_key)
builder = builder.add_extension(
    x509.BasicConstraints(ca=True, path_length=None),
    critical=True)
certificate = builder.sign(
    private_key=private_key, algorithm=hashes.SHA256(),
    backend=default_backend()
)
private_bytes = private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.TraditionalOpenSSL,
    encryption_algorithm=serialization.NoEncrption())
public_bytes = certificate.public_bytes(
    encoding=serialization.Encoding.PEM)
with open("ca.pem", "wb") as fout:
    fout.write(private_bytes + public_bytes)
with open("ca.crt", "wb") as fout:
    fout.write(public_bytes)

通常,真正的 CA 会需要证书签名请求(CSR)来签名证书。但是,当你是自己的 CA 时,你可以制定自己的规则!可以径直签名你想要的内容。

继续集成测试的例子,你可以创建私钥并立即签名相应的公钥。注意 COMMON_NAME 需要是 https URL 中的“服务器名称”。如果你已配置名称查询,你需要服务器能响应对 service.test.local 的请求。

service_private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048,
    backend=default_backend()
)
service_public_key = service_private_key.public_key()
builder = x509.CertificateBuilder()
builder = builder.subject_name(x509.Name([
   x509.NameAttribute(NameOID.COMMON_NAME, 'service.test.local')
]))
builder = builder.not_valid_before(yesterday)
builder = builder.not_valid_after(tomorrow)
builder = builder.public_key(public_key)
certificate = builder.sign(
    private_key=private_key, algorithm=hashes.SHA256(),
    backend=default_backend()
)
private_bytes = service_private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.TraditionalOpenSSL,
    encryption_algorithm=serialization.NoEncrption())
public_bytes = certificate.public_bytes(
    encoding=serialization.Encoding.PEM)
with open("service.pem", "wb") as fout:
    fout.write(private_bytes + public_bytes)

现在 service.pem 文件有一个私钥和一个“有效”的证书:它已由本地的 CA 签名。该文件的格式可以给 Nginx、HAProxy 或大多数其他 HTTPS 服务器使用。

通过将此逻辑用在测试脚本中,只要客户端配置信任该 CA,那么就可以轻松创建看起来真实的 HTTPS 服务器。


via: https://opensource.com/article/19/4/certificate-authority

作者:Moshe Zadka 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

关于 DNS 和根证书你需要了解的内容。

由于最近发生的一些事件,我们(Privacy Today 组织)感到有必要写一篇关于此事的短文。它适用于所有读者,因此它将保持简单 —— 技术细节可能会在稍后的文章发布。

什么是 DNS,为什么它与你有关?

DNS 的意思是 域名系统 Domain Name System ,你每天都会接触到它。每当你的 Web 浏览器或任何其他应用程序连接到互联网时,它就很可能会使用域名。简单来说,域名就是你键入的地址:例如 duckduckgo.com。你的计算机需要知道它所导向的地方,会向 DNS 解析器寻求帮助。而它将返回类似 176.34.155.23 这样的 IP —— 这就是连接时所需要知道的公开网络地址。 此过程称为 DNS 查找。

这对你的隐私、安全以及你的自由都有一定的影响:

隐私

由于你要求解析器获取域名的 IP,因此它会确切地知道你正在访问哪些站点,并且由于“物联网”(通常缩写为 IoT),甚至它还知道你在家中使用的是哪个设备。

安全

你可以相信解析器返回的 IP 是正确的。有一些检查措施可以确保如此,在正常情况下这一般不是问题。但这些可能措施会被破坏,这就是写作本文的原因。如果返回的 IP 不正确,你可能会被欺骗引向了恶意的第三方 —— 甚至你都不会注意到任何差异。在这种情况下,你的隐私会受到更大的危害,因为不仅会被跟踪你访问了什么网站,甚至你访问的内容也会被跟踪。第三方可以准确地看到你正在查看的内容,收集你输入的个人信息(例如密码)等等。你的整个身份可以轻松接管。

自由

审查通常是通过 DNS 实施的。这不是最有效的方法,但它非常普遍。即使在西方国家,它也经常被公司和政府使用。他们使用与潜在攻击者相同的方法;当你查询 IP 地址时,他们不会返回正确的 IP。他们可以表现得就好像某个域名不存在,或完全将访问指向别处。

DNS 查询的方式

由你的 ISP 提供的第三方 DNS 解析器

大多数人都在使用由其互联网接入提供商(ISP)提供的第三方解析器。当你连接调制解调器时(LCTT 译注:或宽带路由器),这些 DNS 解析器就会被自动取出,而你可能从来没注意过它。

你自己选择的第三方 DNS 解析器

如果你已经知道 DNS 意味着什么,那么你可能会决定使用你选择的另一个 DNS 解析器。这可能会改善这种情况,因为它使你的 ISP 更难以跟踪你,并且你可以避免某些形式的审查。尽管追踪和审查仍然是可能的,但这种方法并没有被广泛使用。

你自己(本地)的 DNS 解析器

你可以自己动手,避免使用别人的 DNS 解析器的一些危险。如果你对此感兴趣,请告诉我们。

根证书

什么是根证书?

每当你访问以 https 开头的网站时,你都会使用它发送的证书与之通信。它使你的浏览器能够加密通信并确保没有人可以窥探。这就是为什么每个人都被告知在登录网站时要注意 https(而不是 http)。证书本身仅用于验证是否为某个域所生成。以及:

这就是根证书的来源。可以其视为一个更高的级别,用来确保其下的级别是正确的。它验证发送给你的证书是否已由证书颁发机构授权。此权限确保创建证书的人实际上是真正的运营者。

这也被称为信任链。默认情况下,你的操作系统包含一组这些根证书,以确保该信任链的存在。

滥用

我们现在知道:

  • DNS 解析器在你发送域名时向你发送 IP 地址
  • 证书允许加密你的通信,并验证它们是否为你访问的域生成
  • 根证书验证该证书是否合法,并且是由真实站点运营者创建的

怎么会被滥用呢?

  • 如前所述,恶意 DNS 解析器可能会向你发送错误的 IP 以进行审查。它们还可以将你导向完全不同的网站。
  • 这个网站可以向你发送假的证书。
  • 恶意的根证书可以“验证”此假证书。

对你来说,这个网站看起来绝对没问题;它在网址中有 https,如果你点击它,它会说已经通过验证。就像你了解到的一样,对吗?不对!

它现在可以接收你要发送给原站点的所有通信。这会绕过想要避免被滥用而创建的检查。你不会收到错误消息,你的浏览器也不会发觉。

而你所有的数据都会受到损害!

结论

风险

  • 使用恶意 DNS 解析器总是会损害你的隐私,但只要你注意 https,你的安全性就不会受到损害。
  • 使用恶意 DNS 解析程序和恶意根证书,你的隐私和安全性将完全受到损害。

可以采取的动作

不要安装第三方根证书!只有非常少的例外情况才需要这样做,并且它们都不适用于一般最终用户。

不要被那些“广告拦截”、“军事级安全”或类似的东西营销噱头所吸引。有一些方法可以自行使用 DNS 解析器来增强你的隐私,但安装第三方根证书永远不会有意义。你正在将自己置身于陷阱之中。

实际看看

警告

有位友好的系统管理员提供了一个现场演示,你可以实时看到自己。这是真事。

千万不要输入私人数据!之后务必删除证书和该 DNS!

如果你不知道如何操作,那就不要安装它。虽然我们相信我们的朋友,但你不要随便安装随机和未知的第三方根证书。

实际演示

链接在这里:http://https-interception.info.tm/

  • 设置所提供的 DNS 解析器
  • 安装所提供的根证书
  • 访问 https://paypal.com 并输入随机登录数据
  • 你的数据将显示在该网站上

延伸信息

如果你对更多技术细节感兴趣,请告诉我们。如果有足够多感兴趣的人,我们可能会写一篇文章,但是目前最重要的部分是分享基础知识,这样你就可以做出明智的决定,而不会因为营销和欺诈而陷入陷阱。请随时提出对你很关注的其他主题。

这篇文章来自 Privacy Today 频道Privacy Today 是一个关于隐私、开源、自由哲学等所有事物的组织!

所有内容均根据 CC BY-NC-SA 4.0 获得许可。(署名 - 非商业性使用 - 共享 4.0 国际)。


via: https://lushka.al/dns-and-certificates/

作者:Anxhelo Lushka 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

了解如何验证某人所声称的身份。

上一篇文章中,我们概述了密码学并讨论了密码学的核心概念: 保密性 confidentiality (让数据保密)、 完整性 integrity (防止数据被篡改)和 身份认证 authentication (确认数据源的 身份 identity )。由于要在存在各种身份混乱的现实世界中完成身份认证,人们逐渐建立起一个复杂的 技术生态体系 technological ecosystem ,用于证明某人就是其声称的那个人。在本文中,我们将大致介绍这些体系是如何工作的。

快速回顾公钥密码学及数字签名

互联网世界中的身份认证依赖于公钥密码学,其中密钥分为两部分:拥有者需要保密的私钥和可以对外公开的公钥。经过公钥加密过的数据,只能用对应的私钥解密。举个例子,对于希望与记者建立联系的举报人来说,这个特性非常有用。但就本文介绍的内容而言,私钥更重要的用途是与一个消息一起创建一个 数字签名 digital signature ,用于提供完整性和身份认证。

在实际应用中,我们签名的并不是真实消息,而是经过 密码学哈希函数 cryptographic hash function 处理过的消息 摘要 digest 。要发送一个包含源代码的压缩文件,发送者会对该压缩文件的 256 比特长度的 SHA-256 摘要进行签名,而不是文件本身进行签名,然后用明文发送该压缩包(和签名)。接收者会独立计算收到文件的 SHA-256 摘要,然后结合该摘要、收到的签名及发送者的公钥,使用签名验证算法进行验证。验证过程取决于加密算法,加密算法不同,验证过程也相应不同;而且,很微妙的是签名验证漏洞依然层出不穷。如果签名验证通过,说明文件在传输过程中没有被篡改而且来自于发送者,这是因为只有发送者拥有创建签名所需的私钥。

方案中缺失的环节

上述方案中缺失了一个重要的环节:我们从哪里获得发送者的公钥?发送者可以将公钥与消息一起发送,但除了发送者的自我宣称,我们无法核验其身份。假设你是一名银行柜员,一名顾客走过来向你说,“你好,我是 Jane Doe,我要取一笔钱”。当你要求其证明身份时,她指着衬衫上贴着的姓名标签说道,“看,Jane Doe!”。如果我是这个柜员,我会礼貌的拒绝她的请求。

如果你认识发送者,你们可以私下见面并彼此交换公钥。如果你并不认识发送者,你们可以私下见面,检查对方的证件,确认真实性后接受对方的公钥。为提高流程效率,你可以举办聚会并邀请一堆人,检查他们的证件,然后接受他们的公钥。此外,如果你认识并信任 Jane Doe(尽管她在银行的表现比较反常),Jane 可以参加聚会,收集大家的公钥然后交给你。事实上,Jane 可以使用她自己的私钥对这些公钥(及对应的身份信息)进行签名,进而你可以从一个线上密钥库)获取公钥(及对应的身份信息)并信任已被 Jane 签名的那部分。如果一个人的公钥被很多你信任的人(即使你并不认识他们)签名,你也可能选择信任这个人。按照这种方式,你可以建立一个 信任网络 Web of Trust

但事情也变得更加复杂:我们需要建立一种标准的编码机制,可以将公钥和其对应的身份信息编码成一个 数字捆绑 digital bundle ,以便我们进一步进行签名。更准确的说,这类数字捆绑被称为 证书 cerificate 。我们还需要可以创建、使用和管理这些证书的工具链。满足诸如此类的各种需求的方案构成了 公钥基础设施 public key infrastructure (PKI)。

比信任网络更进一步

你可以用人际关系网类比信任网络。如果人们之间广泛互信,可以很容易找到(两个人之间的)一条 短信任链 short path of trust :就像一个社交圈。基于 GPG 加密的邮件依赖于信任网络,(理论上)只适用于与少量朋友、家庭或同事进行联系的情形。

(LCTT 译注:作者提到的“短信任链”应该是暗示“六度空间理论”,即任意两个陌生人之间所间隔的人一般不会超过 6 个。对 GPG 的唱衰,一方面是因为密钥管理的复杂性没有改善,另一方面 Yahoo 和 Google 都提出了更便利的端到端加密方案。)

在实际应用中,信任网络有一些“ 硬伤 significant problems ”,主要是在可扩展性方面。当网络规模逐渐增大或者人们之间的连接较少时,信任网络就会慢慢失效。如果信任链逐渐变长,信任链中某人有意或无意误签证书的几率也会逐渐增大。如果信任链不存在,你不得不自己创建一条信任链,与其它组织建立联系,验证它们的密钥以符合你的要求。考虑下面的场景,你和你的朋友要访问一个从未使用过的在线商店。你首先需要核验网站所用的公钥属于其对应的公司而不是伪造者,进而建立安全通信信道,最后完成下订单操作。核验公钥的方法包括去实体店、打电话等,都比较麻烦。这样会导致在线购物变得不那么便利(或者说不那么安全,毕竟很多人会图省事,不去核验密钥)。

如果世界上有那么几个格外值得信任的人,他们专门负责核验和签发网站证书,情况会怎样呢?你可以只信任他们,那么浏览互联网也会变得更加容易。整体来看,这就是当今互联网的工作方式。那些“格外值得信任的人”就是被称为 证书颁发机构 cerificate authoritie (CA)的公司。当网站希望获得公钥签名时,只需向 CA 提交 证书签名请求 certificate signing request (CSR)。

CSR 类似于包括公钥和身份信息(在本例中,即服务器的主机名)的 存根 stub 证书,但 CA 并不会直接对 CSR 本身进行签名。CA 在签名之前会进行一些验证。对于一些证书类型(LCTT 译注: 域名证实 Domain Validated (DV) 类型),CA 只验证申请者的确是 CSR 中列出主机名对应域名的控制者(例如通过邮件验证,让申请者完成指定的域名解析)。对于另一些证书类型 (LCTT 译注:链接中提到 扩展证实 Extended Validated (EV)类型,其实还有 OV Organization Validated 类型),CA 还会检查相关法律文书,例如公司营业执照等。一旦验证完成,CA(一般在申请者付费后)会从 CSR 中取出数据(即公钥和身份信息),使用 CA 自己的私钥进行签名,创建一个(签名)证书并发送给申请者。申请者将该证书部署在网站服务器上,当用户使用 HTTPS (或其它基于 TLS 加密的协议)与服务器通信时,该证书被分发给用户。

当用户访问该网站时,浏览器获取该证书,接着检查证书中的主机名是否与当前正在连接的网站一致(下文会详细说明),核验 CA 签名有效性。如果其中一步验证不通过,浏览器会给出安全警告并切断与网站的连接。反之,如果验证通过,浏览器会使用证书中的公钥来核验该服务器发送的签名信息,确认该服务器持有该证书的私钥。有几种算法用于协商后续通信用到的 共享密钥 shared secret key ,其中一种也用到了服务器发送的签名信息。 密钥交换 key exchange 算法不在本文的讨论范围,可以参考这个视频,其中仔细说明了一种密钥交换算法。

建立信任

你可能会问,“如果 CA 使用其私钥对证书进行签名,也就意味着我们需要使用 CA 的公钥验证证书。那么 CA 的公钥从何而来,谁对其进行签名呢?” 答案是 CA 对自己签名!可以使用证书公钥对应的私钥,对证书本身进行签名!这类签名证书被称为是 自签名的 self-signed ;在 PKI 体系下,这意味着对你说“相信我”。(为了表达方便,人们通常说用证书进行了签名,虽然真正用于签名的私钥并不在证书中。)

通过遵守浏览器操作系统供应商建立的规则,CA 表明自己足够可靠并寻求加入到浏览器或操作系统预装的一组自签名证书中。这些证书被称为“ 信任锚 trust anchor ”或 CA 根证书 root CA certificate ,被存储在根证书区,我们 约定 implicitly 信任该区域内的证书。

CA 也可以签发一种特殊的证书,该证书自身可以作为 CA。在这种情况下,它们可以生成一个证书链。要核验证书链,需要从“信任锚”(也就是 CA 根证书)开始,使用当前证书的公钥核验下一层证书的签名(或其它一些信息)。按照这个方式依次核验下一层证书,直到证书链底部。如果整个核验过程没有问题,信任链也建立完成。当向 CA 付费为网站签发证书时,实际购买的是将证书放置在证书链下的权利。CA 将卖出的证书标记为“不可签发子证书”,这样它们可以在适当的长度终止信任链(防止其继续向下扩展)。

为何要使用长度超过 2 的信任链呢?毕竟网站的证书可以直接被 CA 根证书签名。在实际应用中,很多因素促使 CA 创建 中间 CA 证书 intermediate CA certificate ,最主要是为了方便。由于价值连城,CA 根证书对应的私钥通常被存放在特定的设备中,一种需要多人解锁的 硬件安全模块 hardware security module (HSM),该模块完全离线并被保管在配备监控和报警设备的地下室中。

CA/浏览器论坛 CAB Forum, CA/Browser Forum 负责管理 CA,要求任何与 CA 根证书(LCTT 译注:就像前文提到的那样,这里是指对应的私钥)相关的操作必须由人工完成。设想一下,如果每个证书请求都需要员工将请求内容拷贝到保密介质中、进入地下室、与同事一起解锁 HSM、(使用 CA 根证书对应的私钥)签名证书,最后将签名证书从保密介质中拷贝出来;那么每天为大量网站签发证书是相当繁重乏味的工作。因此,CA 创建内部使用的中间 CA,用于证书签发自动化。

如果想查看证书链,可以在 Firefox 中点击地址栏的锁型图标,接着打开页面信息,然后点击“安全”面板中的“查看证书”按钮。在本文写作时,opensource.com 使用的证书链如下:

DigiCert High Assurance EV Root CA
    DigiCert SHA2 High Assurance Server CA
        opensource.com

中间人

我之前提到,浏览器需要核验证书中的主机名与已经建立连接的主机名一致。为什么需要这一步呢?要回答这个问题,需要了解所谓的 中间人攻击 man-in-the-middle, MIMT 。有一类网络攻击可以让攻击者将自己置身于客户端和服务端中间,冒充客户端与服务端连接,同时冒充服务端与客户端连接。如果网络流量是通过 HTTPS 传输的,加密的流量无法被窃听。此时,攻击者会创建一个代理,接收来自受害者的 HTTPS 连接,解密信息后构建一个新的 HTTPS 连接到原始目的地(即服务端)。为了建立假冒的 HTTPS 连接,代理必须返回一个攻击者具有对应私钥的证书。攻击者可以生成自签名证书,但受害者的浏览器并不会信任该证书,因为它并不是根证书库中的 CA 根证书签发的。换一个方法,攻击者使用一个受信任 CA 签发但主机名对应其自有域名的证书,结果会怎样呢?

再回到银行的那个例子,我们是银行柜员,一位男性顾客进入银行要求从 Jane Doe 的账户上取钱。当被要求提供身份证明时,他给出了 Joe Smith 的有效驾驶执照。如果这个交易可以完成,我们无疑会被银行开除。类似的,如果检测到证书中的主机名与连接对应的主机名不一致,浏览器会给出类似“连接不安全”的警告和查看更多内容的选项。在 Firefox 中,这类错误被标记为 SSL_ERROR_BAD_CERT_DOMAIN

我希望你阅读完本文起码记住这一点:如果看到这类警告,不要无视它们!它们出现意味着,或者该网站配置存在严重问题(不推荐访问),或者你已经是中间人攻击的潜在受害者。

总结

虽然本文只触及了 PKI 世界的一些皮毛,我希望我已经为你展示了便于后续探索的大致蓝图。密码学和 PKI 是美与复杂性的结合体。越深入研究,越能发现更多的美和复杂性,就像分形那样。


via: https://opensource.com/article/18/7/private-keys

作者:Alex Wood 选题:lujun9972 译者:pinewall 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

最近关于沃通和 StartCom 这两家 CA 公司的消息让人们再次关注到了网络隐私和安全的问题。随着 Mozilla苹果谷歌对这两家 CA 公司处罚落定,很多使用这两家 CA 所签发证书的网站纷纷寻求新的证书签发商。这里面固然有不少可信赖的 CA 公司可以提供服务,不过,有另外一个非盈利组织却为大家提供了免费、可靠和安全的 SSL 证书服务,这就是 Let's Encrypt 项目。

Let's Encrypt 项目是由 互联网安全研究小组 ISRG,Internet Security Research Group 主导并开发的一个新型 数字证书认证机构 CA,Certificate Authority 。该项目旨在开发一个自由且开放的自动化 CA 套件,并向公众提供相关的证书免费签发服务以降低安全通讯的财务、技术和教育成本。

网站的完全加密是非常有必要的,这样每个人都可以随意在网上畅游而不用担心他们的活动被监视、拦截和修改。

Let’s Encrypt 的做法与一般的 CA 服务商不同。他们为那些需要加密的网站提供了免费、易用的获取和管理证书的服务,而且在全球的每一个国家都可以使用。这些服务可以帮助人们或组织战胜来自经济、技术和培训方面的障碍,在互联网上安全地通讯。

仅仅在 Let’s Encrypt 运营了 10 个月之后,加密的页面数量就有了快速提升!这里面,Let’s Encrypt 项目居功甚伟,采用加密 Let’s Encrypt 的页面 90% 都是之前从未进行过加密的。

然而,互联网上还有超过一半的页面仍然没有加密。所以 Let’s Encrypt 还任重而道远,为了达成让互联网全都变成加密的这一目标,他们需要你的帮助!因此 Let’s Encrypt 在众筹网站 generosity.com 上发起了众筹,募集更多的运营资金,以期做的更好!

如果您能捐助他们,您就为建立一个更安全的互联网埋下了一块基石。您所捐赠的每一块钱,都可以帮助 Let’s Encrypt 为所有用户创建一个尊重隐私的互联网体验。

他们划定了几个从 $25 到 $42000 不等的捐赠级别,并且为了感谢您的支持,会提供给您一些有趣的礼品以示谢意:

第一个级别 $25,您将收到一声感谢!

第二个级别 $50,您将收到一些精美的贴纸,可以贴在你的保险杠、水杯或者其它的什么地方。

第三个级别是 $100,他们叫这个“To Encryption and Beyond!”,礼品是这些漂亮的、合身的 T恤。

如果您捐赠了 $250,您将同时收到 T 恤和贴纸。

更高额度的捐赠就不在这里一一列出了,富有爱心的土豪可以移步这个众筹网站去看看。

如果您暂时手头比较紧张,你还有其它的几种方式支持:

  • 分享这篇文章或其中的视频到你常用的社交媒体中。
  • 转发这个的捐赠计划。
  • 参与他们的社区论坛。
  • 帮助他们找到 bug 以便可以修复它。

关于 Let's Encrypt 的更多信息,您可以访问其官网: https://letsencrypt.org/ ;如何使用他们的服务,你可以参考这篇文章