#946 转载:康威定律

2024-03-04

几乎所有我喜欢的软件架构师,都认同康威定律(Conway Law),认为这个定律非常重要,足以影响到所有系统。而且,你没法与之抗争,想要抗拒康威定律注定要失败。

康威定律的最好表述是:“任何系统的构成,都反映了设计这个系统的组织结构。”

它的出处是 Melvin Conway 在 1968 年写的一篇文章。后来,弗雷德·布鲁克斯(Fred Brooks)在著名的《人月神话》(The Mythical Man-Month)引用了这条定律。

Melvin Conway 观察到,软件系统的架构看起来与构建它的开发团队的组织结构非常相似。

最初的描述是,如果一个团队编写一个编译器,那么它将是一个单通道编译器;但是,如果两个团队共同开发,那么它将是一个双通道编译器。这个描述后来被发现,广泛适用于大量系统。

正如我的同事 Chris Ford 对我说的:“软件耦合是由人类交流促成的。” 如果我可以轻松与代码作者交谈,那么我就更容易对代码有更深入的了解,因此我的代码更容易耦合到该代码。

应对康威定律的第一步是不要与之抗争。我仍然记得一位技术主管,他刚刚被任命为 ​​ 一个大型新项目的架构师,该项目由分布在世界各地不同城市的六个团队组成。“我做出了第一个架构决定”,他告诉我:“就是这个系统将有六个主要的子系统。我不知道它们会是什么子系统,但肯定会有六个。”

为了适应康威定律,现在有一种策略,就是一旦定下软件架构,就相应改变组织结构,让紧密耦合模块的开发者更容易沟通。

#945 转载:剖析 SSL 证书

2024-02-27

Hello! In my networking zine (which everyone will be able to see soon), there is a page about TLS/SSL (basically this tweet). But as happens when you write 200 words about a thing on a page, there is a lot more interesting stuff to say. So in this post we will dissect an SSL certificates and try to understand it!

你好! 在我的网络杂志(每个人很快就能看到)中,有一个关于 TLS/SSL 的页面(基本上是这条推文)。 但当你在一页上写下 200 个关于某件事的字时,就会发现有很多更有趣的东西要说。 因此,在这篇文章中,我们将剖析 SSL 证书并尝试理解它!

I am not a security person and I am not going to give you security advice for your website (want to know what TLS ciphers you should use? I have no idea!!!). But! I think it’s interesting to know what it means to “issue a SSL certificate” and I can talk about that a little.

我不是安全人员,我不会为您的网站提供安全建议(想知道您应该使用什么 TLS 密码?我不知道!!!)。 但! 我认为了解“颁发 SSL 证书”的含义很有趣,我可以稍微讨论一下。

TLS: newer version of SSL

I was confused about what this “TLS” thing was for a long time. Basically newer versions of SSL are called TLS (the version after SSL 3.0 is TLS 1.0). I’m going to just call it “SSL” throughout because that is less confusing to me.

很长一段时间我都对“TLS”这个东西感到困惑。 基本上较新版本的 SSL 称为 TLS(SSL 3.0 之后的版本是 TLS 1.0)。 我将自始至终将其称为“SSL”,因为这对我来说不那么令人困惑。

What’s a certificate?

Suppose I’m checking my email at https://mail.google.com
假设我正在 https://mail.google.com 检查我的电子邮件

mail.google.com is running a HTTPS server on port 443. I want to make sure that I’m actually talking to mail.google.com and not some other random server on the internet owned by EVIL PEOPLE.
“mail.google.com”正在端口 443 上运行 HTTPS 服务器。我想确保我实际上与 mail.google.com 进行通信,而不是与 EVIL PEOPLE 拥有的互联网上的其他随机服务器进行通信 。

This “certificate” business was kind of mysterious to me for a very long time. One day my cool coworker Ray told me that I could connect to a server on the command line and download its certificate!
很长一段时间以来,这个“证书”业务对我来说有点神秘。 有一天,我的酷同事 Ray 告诉我,我可以通过命令行连接到服务器并下载其证书!

(If you want to just look at an SSL certificate, you can click on the green lock in your browser and reliably get all the information you need. But this is more fun.)
(如果您只想查看 SSL 证书,您可以单击浏览器中的绿色锁,可靠地获取您需要的所有信息。但这更有趣。)

So, let’s start by looking at mail.google.com’s certificate and deconstruct it a bit.
那么,让我们首先查看 mail.google.com 的证书并对其进行一些解构。

First, we run openssl s_client -connect mail.google.com:443
首先,我们运行“openssl s_client -connect mail.google.com:443”

This is going to print a bunch of stuff, but we’ll just focus on the certificate. Here, it’s this thing:
这将打印一堆东西,但我们只关注证书。 在这里,就是这个东西:

$ openssl s_client -connect mail.google.com:443
...
-----BEGIN CERTIFICATE-----
MIIElDCCA3ygAwIBAgIIMmzfdZnO9pMwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTcwMTE4MTg1MjExWhcNMTcwNDEyMTg1MDAw
WjBpMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEYMBYGA1UEAwwPbWFp
bC5nb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiYcr
C9Rn7g9xjsg7khqfRPxUnvpgGyCHqJMXxZGtdf+G02d07cPlMEeaGG12vHyVfRZD
tc/F1ZfwenH6gf0uMobtgw7n2NQa7T7qxuqSUDhZsO1sI1LL/Yqy8QHoooOZQWMz
ytuRA18zti4vQV1dCijADh0+NWI1GDUAKidbaH/fBRrStqBev5Bhq3ZaGj3fDjAO
7CG0Wk3n4Ov2yg44XOdgkLMzjdnbV8l6cZDC7lCK1VsEU1mEd0O0Dw4OcnHLuBPw
IkioZayhPOXDXUS+bhpmtEiCkt8kbHG6jNMC4m8t62Jaf/Si3XNcHhDa4wPCTvid
X//PuuNlRZVg3NjK/wIDAQABo4IBXjCCAVowHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMCwGA1UdEQQlMCOCD21haWwuZ29vZ2xlLmNvbYIQaW5ib3guZ29v
Z2xlLmNvbTBoBggrBgEFBQcBAQRcMFowKwYIKwYBBQUHMAKGH2h0dHA6Ly9wa2ku
Z29vZ2xlLmNvbS9HSUFHMi5jcnQwKwYIKwYBBQUHMAGGH2h0dHA6Ly9jbGllbnRz
MS5nb29nbGUuY29tL29jc3AwHQYDVR0OBBYEFI69aYCEtb2swbJJR3cMOTdcfvZ4
MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUSt0GFhu89mi1dvWBtrtiGrpagS8w
IQYDVR0gBBowGDAMBgorBgEEAdZ5AgUBMAgGBmeBDAECAjAwBgNVHR8EKTAnMCWg
I6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3JsMA0GCSqGSIb3DQEB
CwUAA4IBAQAhiqQIwkGp1NmlLq89gjoAfpwaapHuRixxl2S54fyu/4WOHJJafqVA
Tya9J7GTUCyQ6nszCdVizVP26h9TKOs9LJw5jWV9SOnPU2UZKvrNnOUi2FUkCcuD
lsADdKSXNzye3jB88TENrWC/y3ysPdAgPO/sXzyRvNw8SVKl2+RqMDpSRpBptF9e
Lp+WLAM3xKS5SPwCNdCiA332o7qiKRKQm/6bbIWnm7hp/ZnLxbyKaIVytRdiwRNp
O/TTpRv2C708GA3PH6i1pYE86xm3w7lGhN9OiCZpKOJD6ZUH3W20idgPKYPBCO/N
Op2AF3I4iUGeQjXFVLgS6mjUvdLndL9G
-----END CERTIFICATE-----

So far, this is unintelligible nonsense. “MIIElDcca… WHAT?!”

It turns out that this nonsense is a format called “X509”, and the openssl command knows how to decode it.

So I saved this blob of text to a file called cert.pem. You can save it to your computer from this gist if you want to follow along.

Our next mission is to parse this certificate. We do that like this:

到目前为止,这都是难以理解的废话。 “MIIElDcca……什么?!”

原来这个废话是一种叫做“X509”的格式,而openssl命令知道如何解码它。

因此,我将这段文本保存到名为“cert.pem”的文件中。 如果您想继续操作,可以根据此要点将其保存到您的计算机上。

我们的下一个任务是解析此证书。 我们这样做:

$ openssl x509 -in cert.pem -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3633524695565792915 (0x326cdf7599cef693)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2
        Validity
            Not Before: Jan 18 18:52:11 2017 GMT
            Not After : Apr 12 18:50:00 2017 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=mail.google.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:89:87:2b:0b:d4:67:ee:0f:71:8e:c8:3b:92:1a:
                    9f:44:fc:54:9e:fa:60:1b:20:87:a8:93:17:c5:91:
                    .... blah blah blah ............
                    c2:4e:f8:9d:5f:ff:cf:ba:e3:65:45:95:60:dc:d8:
                    ca:ff
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:mail.google.com, DNS:inbox.google.com

            X509v3 Subject Key Identifier:
                8E:BD:69:80:84:B5:BD:AC:C1:B2:49:47:77:0C:39:37:5C:7E:F6:78
    Signature Algorithm: sha256WithRSAEncryption
         21:8a:a4:08:c2:41:a9:d4:d9:a5:2e:af:3d:82:3a:00:7e:9c:
         1a:6a:91:ee:46:2c:71:97:64:b9:e1:fc:ae:ff:85:8e:1c:92:
         ......... blah blah blah more goes here ...........

This is a lot of stuff. Here are the parts of this that I understand

  • CN=mail.google.com is the “common name”. Counterintuitively you should ignore this field and look at the “subject alternative name” field instead
  • an expiry date: Apr 12 18:50:00 2017 GMT
  • The X509v3 Subject Alternative Name: section has the list of domains that this certificate works for. This is mail.google.com and inbox.google.com, which makes sense – they’re both email domains.
  • The Public Key Info section tells us the public key that we’re going to use to communicate with mail.google.com. We do not have time to explain public key cryptography right now, but this is basically the encryption key we’re going to use to talk secretly.
  • Lastly, the signature is a really important thing. Basically anyone could make a certificate for mail.google.com. I could make one right now! But if I gave you that certificate, you would have no reason to believe that it is a real certificate

So let’s talk about certificate signing.

这是很多东西。 这是我理解的部分

  • CN=mail.google.com 是“通用名称”。 与直觉相反,您应该忽略此字段并查看“主题备用名称”字段
  • 到期日期:2017 年 4 月 12 日 18:50:00 GMT
  • “X509v3 使用者备用名称:”部分包含此证书适用的域列表。 这是 mail.google.com 和 inbox.google.com,这是有道理的 – 它们都是电子邮件域。
  • “公钥信息”部分告诉我们将用来与 mail.google.com 进行通信的公钥。 我们现在没有时间解释公钥密码学,但这基本上是我们将用来秘密交谈的加密密钥。
  • 最后,签名是一件非常重要的事情。 基本上任何人都可以为 mail.google.com 制作证书。 我现在就可以做一个! 但如果我给你那个证书,你就没有理由相信这是一个真正的证书

那么我们来谈谈证书签名。

certificate signing

Every certificate on the internet is basically two parts put together

  1. A certificate (the domain name it’s valid for and public key and other stuff)
  2. signature by someone else. This basically says, “hey, this is okay, Visa says so”

I have a bunch of certificates on my computer in /etc/ssl/certs. Those are the certificates my computer trusts to sign other certificates. For example, I have /etc/ssl/certs/Staat_der_Nederlanden_EV_Root_CA.pem on my laptop. Some certificate from the Netherlands! Who knows! If they signed a mail.google.com certificate, my computer would be like “yep, looks great, sounds awesome”.

If some random person across the street signed a certificate, my computer would be like “I have no idea who you are”, and reject the certificate.

The mail.google certificate is

  • s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
  • which is signed by a “Google Internet Authority G2” certificate
  • which is signed by a “GeoTrust Global CA” certificate
  • which is signed by an “Equifax Secure Certificate Authority” certificate

I have an /etc/ssl/certs/GeoTrust_Global_CA.pem file on my computer, which I think is why I trust this mail.google.com certificate. (Geotrust signed Google’s certificate, and Google signed mail.google.com)

互联网上的每个证书基本上都是由两部分组合而成

  1. 证书(有效的域名和公钥等)
  2. 其他人的签名。 这基本上是在说,“嘿,没关系,Visa 是这么说的”

我的计算机上的 /etc/ssl/certs 中有一堆证书。 这些是我的计算机信任的用于签署其他证书的证书。 例如,我的笔记本电脑上有“/etc/ssl/certs/Staat_der_Nederlanden_EV_Root_CA.pem”。 荷兰的一些证书! 谁知道! 如果他们签署了“mail.google.com”证书,我的计算机就会说“是的,看起来很棒,听起来很棒”。

如果街对面的某个随机人签署了证书,我的计算机就会像“我不知道你是谁”一样,并拒绝该证书。

mail.google 证书是

  • s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
  • 由“Google Internet Authority G2”证书签名
  • 由“GeoTrust Global CA”证书签名
  • 由“Equifax 安全证书颁发机构”证书签名

我的计算机上有一个 /etc/ssl/certs/GeoTrust_Global_CA.pem 文件,我认为这就是我信任此 mail.google.com 证书的原因。 (Geotrust 签署了 Google 的证书,Google 签署了 mail.google.com)

what does getting a certificate issued look like?

So when you get a certificate issued, basically how it works is:

  1. You generate the first half of the certificate (“jvns.ca! expires on X date! This is my public key!”). This part is public.
  2. At the same time, you generate a private key for you certificate. You keep this very secret and safe and do not show it to anybody. You’ll use this key every time you establish an SSL connection.
  3. You pay a certificate authority (CA) that other computers trust to sign your certificate for you. Certificate authorities are supposed to have integrity, so they are supposed to actually make sure that when they sign certificates, the person they give the cert to actually owns the domain.
  4. You configure your website with your signed certificate and use it to prove that you are really you! Success!

This “certificate authorities are supposed to have integrity thing” I think is why people get so mad when there are issues like this with Symantec where they generated test certificates “to unregistered domains and domains for which Symantec did not have authorization from the domain owner”

因此,当您获得颁发的证书时,其工作原理基本上是:

  1. 您生成证书的前半部分(“jvns.ca!在 X 日期到期!这是我的公钥!”)。 这部分是公开的。
  2. 同时,您为证书生成私钥。 您将其保密且安全,并且不向任何人展示。 每次建立 SSL 连接时都将使用此密钥。
  3. 您向其他计算机信任的证书颁发机构 (CA) 付费,由其为您签署证书。 证书颁发机构应该具有完整性,因此他们应该真正确保在签署证书时,他们向其提供证书的人实际上拥有该域。
  4. 您使用您的签名证书配置您的网站,并用它来证明您确实是您! 成功!

我认为“证书颁发机构应该保持诚信”,这就是为什么人们在出现[赛门铁克的此类问题](https://www.symantec.com/page.jsp?id=test-certs- 更新),他们为“未注册的域以及赛门铁克未获得域所有者授权的域”生成了测试证书

certificate transparency

The last thing we are going to talk about is certificate transparency. This is a super interesting thing and has a good website and I am almost certainly going to mangle it.

I will try anyway!

So, we said that certificate authorities are “supposed to have integrity”. But there are SO MANY certificate authorities that my computer trusts! And at any time one of them could sign a rogue certificate for mail.google.com. That’s no good.

This isn’t a hypothetical issue – the certificate transparency website talks about more than one instance where a CA has been compromised or otherwise has made a mistake.

So, here’s the deal. At any given time, Google knows all the valid certificates that are supposed to exist for mail.google.com (there is probably only one or something). So certificate transparency is basically a way to make sure that if there is a certificate in circulation for mail.google.com that they DON’T know about, that they can find out.

Here are the steps, as I understand them

  1. Every time any CA signs a certificate, they are supposed to put into a global public “certificate log”
  2. Also the Googlebot puts every certificate it finds on the internet into the certificate log
  3. If a certificate isn’t in the log, then my browser will not accept it (or will stop accepting it in the future or something)
  4. Anyone can look at the log at any time to find out if there are rogue certificates in there

So if that CA in the Netherlands signs an evil mail.google.com certificate, they either have to put it in the public log (and Google will find out about their evil ways) or leave it out of the public log (and browsers will reject it).

我们要讨论的最后一件事是证书透明度。 这是一件非常有趣的事情,并且有一个很好的网站,我几乎肯定会破坏它。

无论如何我都会尝试!

因此,我们说证书颁发机构“应该具有完整性”。 但是我的计算机信任很多证书颁发机构! 他们中的任何一个人都可以随时为 mail.google.com 签署一份流氓证书。 那可不行。

这不是一个假设的问题 - 证书透明度 网站讨论了不止一个 CA 已被泄露或以其他方式做出了 错误。

所以,这就是交易。 在任何给定时间,Google 知道“mail.google.com”应存在的所有有效证书(可能只有一个或某项)。 因此,证书透明度基本上是一种确保 mail.google.com 是否有他们不知道的证书在流通的方法,他们可以找到。

据我了解,这是步骤

  1. 每次任何 CA 签署证书时,他们都应该放入全球公共“证书日志”中
  2. Googlebot 还将它在互联网上找到的每个证书放入证书日志中
  3. 如果证书不在中,那么我的浏览器将不会接受它(或者将来会停止接受它或其他什么)
  4. 任何人都可以随时查看日志,了解其中是否存在流氓证书

因此,如果荷兰的 CA 签署了邪恶的 mail.google.com 证书,他们要么必须将其放入公共日志中(Google 会发现他们的邪恶方式),要么将其从公共日志中删除(浏览器将 拒绝它)。

setting up SSL stuff is hard

Okay! We have downloaded a SSL certificate and dissected it and learned a few things about it. Hopefully some of you have learned something!

Picking the right settings for your SSL certificates and SSL configuration on your webserver is confusing. As far as I understand it there are about 3 billion settings. Here is an example of an SSL Labs result for mail.google.com. There is all this stuff like OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 on that page (for real, that is a real thing.). I’m happy there are tools like SSL Labs that help mortals make sense of all of it.

Someone told me https://cipherli.st/ is a way to pick secure SSL configuration if you’re not sure what to do. I don’t know if it’s good or not.

好的! 我们已经下载了 SSL 证书并对其进行了剖析并了解了一些有关它的信息。 希望你们中的一些人学到了一些东西!

为 Web 服务器上的 SSL 证书和 SSL 配置选择正确的设置是令人困惑的。 据我了解,大约有 30 亿个设置。 以下是 mail.google.com 的 SSL 实验室结果示例。 该页面上有诸如“OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256”之类的所有内容(实际上,这是真实的东西。)。 我很高兴有像 SSL Labs 这样的工具可以帮助普通人理解这一切。

有人告诉我,如果您不确定该怎么做,https://cipherli.st/ 是选择安全 SSL 配置的一种方法。 我不知道这好不好。

let’s encrypt is amazing

Also let’s encrypt is really cool! They let you have a certificate for your site and make it secure, and you don’t even need to understand all this stuff about how certificates work on the inside! And it’s FREE.

另外,let’s encrypt 真的很酷! 它们让您拥有网站的证书并确保其安全,您甚至不需要了解所有有关证书内部工作原理的内容! 而且它是免费的。

#944 小儿肺炎

2024-02-10

症状

  • 咳嗽
  • 发烧
  • 呼吸有痰音
  • 食欲不佳
  • 拉肚子(没有消化好的食物,奇怪的气味)
  • 哭闹

药品

  • 双歧杆菌三联活菌胶囊
  • 神曲消食口服液

输液

  • 注射用地塞米松
  • 注射用盐酸头孢替安锋替新
  • 0.9% 氯化纳注射液

雾化

  • 吸入用布地奈德混悬液
  • 吸入用异丙托溴铵溶液

#942 关于熬夜

2024-01-20

最新一期《开发者周刊》上有一个言论击中我了:

有一个名词叫做"报复性熬夜",指的是有些人明明在白天疲劳不堪,晚上却不愿意早睡,宁愿在床上玩手机。
这是因为他们控制不了自己的生活,通过在晚上推迟睡觉,获得一点自己掌控时间的自由感。
-- 《报复性熬夜

我也一直持差不多的观点,白天太多事了,工作的、家庭的,这些时间并不属于我自己,直到晚上、半夜,一片寂静中,才有片刻时间真正可以自由支配。
坐在沙发上,坐在马桶上,抑或躺在床上,刷刷抖音,打打代码。

百度百科对熬夜是这样定义的:

熬夜,汉语词语,意为深夜还不睡。泛指因事通宵或至深夜忍困不眠。出自《清平山堂话本·快嘴李翠莲记》。
熬夜是一种现代生活经常听到或者做到的一种现象,是一种危害人的身体的不良习惯,可导致一些疾病,降低效率。熬夜是不良习惯的一种,容易缺乏内源氧。

报复性熬夜,原文中讲的都是一些老生常谈的内容,伤害身体之类,只有 “获得一点自己掌控时间的自由感” 这一句话表达得非常精彩,比我之前的表达更准确。

熬夜自然是伤身体的,这每个人都知道。
挤出来的这点时间感觉才是真正的休息,从各种角色中抽身出来,做做自己。
难以抵抗这片刻自由的诱惑啊!

#940 Windows 操作习惯养成

2023-12-23

Windows 11

触摸板

  • 单指:点击,双击,双击拖动
  • 双指:滚动,点击(鼠标右键),捏合(缩放场景)
  • 三指:
  • 上、下:多任务视图/显示桌面
  • 左、右:切换应用
  • 点击:搜索
  • 四指:
  • 上、下:多任务视图/显示桌面(调整为:最大化窗口/最小化窗口)
  • 左、右:切换桌面
  • 点击:通知中心

快捷键

按键 作用
Win + ~ 下拉命令行窗口

TAB

按键 作用
Win + Tab 多任务视图
Alt + Tab 切换应用
Alt + Ctrl + Tab 应用切换(应用选择)

任务栏应用

按键 作用
Win + Num 启动任务栏应用/窗口切换
Win + Ctrl + Num 启动任务栏应用/窗口切换(有点不一样)
Win + Shift + Num 启动任务栏应用(新窗口)
Win + Shift + Alt + Num 启动任务栏应用(管理员权限)
Win + Alt + Num 任务栏应用菜单

#938 OpenSSL 检查 HTTPS 和 SMTP (STARTTLS) 连接

2023-12-10

HTTPS

echo | openssl s_client -connect sendcloud.net:443
echo | openssl s_client -showcerts -connect sendcloud.net:443
echo | openssl s_client -showcerts -debug -connect sendcloud.net:443 >/dev/null
echo | openssl s_client -showcerts -debug -connect sendcloud.net:443 2>/dev/null | openssl x509 -inform pem -noout -text

# 导出证书
openssl s_client -connect sendcloud.net:443 </dev/null | openssl x509 -outform pem > sendcloud.net.cer
# 导出所有证书
openssl s_client -showcerts -connect sendcloud.net:443 </dev/null | sed -n '/-----BEGIN/,/-----END/p' > sendcloud.net.cer
# 查看证书信息
openssl s_client -showcerts -connect sendcloud.net:443 </dev/null | sed -n '/-----BEGIN/,/-----END/p' | openssl x509 -noout -text
# 查看证书链上所有证书信息
OLDIFS=$IFS; IFS=':' certs=$(openssl s_client -showcerts -connect sendcloud.net:443 2>/dev/null </dev/null | sed -n '/-----BEGIN/,/-----END/{/-----BEGIN/ s/^/:/; p}'); for cert in ${certs#:}; do echo $cert | openssl x509 -noout -text; done; IFS=$OLDIFS
# # 查看证书链上所有证书 OCSP URI
OLDIFS=$IFS; IFS=':' certs=$(openssl s_client -showcerts -connect sendcloud.net:443 2>/dev/null </dev/null | sed -n '/-----BEGIN/,/-----END/{/-----BEGIN/ s/^/:/; p}'); for cert in ${certs#:}; do echo $cert | openssl x509 -noout -ocsp_uri; done; IFS=$OLDIFS
# -ocsp_uri
# -serial
# -fingerprint
# -subject
# 检查证书在 30 天之后有没有过期
openssl s_client -connect sendcloud.net:443 2>/dev/null </dev/null | openssl x509 -outform pem | openssl x509 -noout -checkend 2592000
# -checkend intmax  Check whether the cert expires in the next arg seconds
# -checkhost val    Check certificate matches host
# -checkemail val   Check certificate matches email
# -checkip val      Check certificate matches ipaddr
echo | openssl s_client -verify_hostname baidu.com -connect sendcloud.net:443 1>/dev/null

SMTP

一样的,只是加 -starttls smtp

echo | openssl s_client -connect smtp.sendcloud.net:25 -starttls smtp
echo | openssl s_client -connect smtp.sendcloud.net:25 -starttls smtp 2>/dev/null | openssl x509 -inform pem -noout -text

其他

校验证书

# echo | openssl s_client -connect smtp.sendcloud.net:25 -starttls smtp 2>/dev/null | openssl verify
# echo | openssl s_client -showcerts -connect smtp.sendcloud.net:25 -starttls smtp 2>/dev/null | openssl verify
echo | openssl s_client -showcerts -connect smtp.sendcloud.net:25 -starttls smtp 2>/dev/null | sed -n '/-----BEGIN/,/-----END/p' > smtp.sendcloud.net.cer
openssl verify -CAfile smtp.sendcloud.net.cer smtp.sendcloud.net.cer

IMAP

echo | openssl s_client -connect imap.126.com:143 -starttls imap

测试 TLS 1.3 支持

echo | openssl s_client -connect smtp.sendcloud.net:25 -starttls smtp -tls1_3

OCSP 检测

用上面的 sendcloud.net.cer 举例,需要将文件中第一个证书和下面的其他证书拆开,分成 sendcloud.cer 和 chain.cer

openssl x509 -noout -ocsp_uri -in sendcloud.cer
# http://ocsp.sectigo.com
openssl ocsp -issuer chain.cer -cert sendcloud.cer -text -url http://ocsp.sectigo.com
# Error querying OCSP responder
# 140052849842064:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:314:Code=400,Reason=Bad Request

遇到上面报错是因为 OSCP 客户端使用 HTTP 1.0,但是服务器端现在都是 1.1,需要 Host 头。

$ openssl ocsp -issuer chain.cer -cert sendcloud.cer -text -url http://ocsp.sectigo.com -header "HOST" "ocsp.sectigo.com"
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 21F3459A10CAA6C84BDA1E3962B127D5338A7C48
          Issuer Key Hash: 17D9D6252767F931C24943D93036448C6CA94FEB
          Serial Number: DB5F1FFAFFB770CA38E8120A6121852E
    Request Extensions:
        OCSP Nonce:
            0410F47624DDB17E9703BFCDCC96E983018B
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 17D9D6252767F931C24943D93036448C6CA94FEB
    Produced At: Dec  9 07:52:17 2023 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 21F3459A10CAA6C84BDA1E3962B127D5338A7C48
      Issuer Key Hash: 17D9D6252767F931C24943D93036448C6CA94FEB
      Serial Number: DB5F1FFAFFB770CA38E8120A6121852E
    Cert Status: good
    This Update: Dec  9 07:52:17 2023 GMT
    Next Update: Dec 16 07:52:16 2023 GMT

    Signature Algorithm: sha256WithRSAEncryption
         5f:65:bf:3e:d1:8c:16:63:76:bc:83:82:b8:a3:67:54:1d:26:
         78:e1:b9:7f:64:c7:61:bc:40:0d:4b:b0:7f:49:29:bc:38:48:
         43:87:a5:dd:a1:e6:b4:74:ce:58:44:24:30:c3:0d:f5:ab:da:
         8c:f9:25:0e:3e:e2:fe:5a:64:5f:32:d9:f5:15:6f:0c:0c:89:
         97:30:f6:6c:07:56:6e:54:81:4f:d3:22:1f:16:94:a0:2b:99:
         49:2f:2c:0f:c8:b7:b4:90:2f:60:01:54:9c:f9:34:c0:c6:e1:
         09:3f:93:d4:dd:a7:0b:34:bb:cb:4b:06:c3:5a:8c:fc:dc:85:
         4f:9d:a7:08:c3:22:98:06:b8:b9:d4:47:51:9c:36:43:f3:53:
         db:f5:d1:2f:4c:a6:97:c7:5a:f5:15:04:c4:94:a4:9e:95:4c:
         03:fd:5a:60:b8:4c:75:e8:02:74:e4:80:1c:8f:17:85:8a:a2:
         9e:b9:5d:74:4a:2e:7d:9f:5e:d8:40:6b:60:63:74:3f:dc:11:
         d4:f6:b4:86:6e:6b:83:8a:ff:57:cf:b4:41:1f:a3:66:b2:e2:
         00:6a:3a:33:dc:c3:3d:13:1d:37:97:d9:9c:d9:b5:9b:24:74:
         24:82:7a:f9:ca:51:b3:39:24:e3:90:f4:ff:4b:8e:be:f8:0f:
         ec:7a:16:55
WARNING: no nonce in response
Response Verify Failure
139766041024400:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
sendcloud.cer: good
        This Update: Dec  9 07:52:17 2023 GMT
        Next Update: Dec 16 07:52:16 2023 GMT

#937 异常流量监控

2023-12-09

突然来了大量客户请求,我们无法判断这些请求是正常的,还是客户被攻击所致。为了避免产生严重客损,我们需要识别到这些突然出现的流量高峰,并进行通知以及执行一些处理措施。

客户配置

比如:

request_limit = {
  rate: {
    // 客户配置
    3600: 1000, // 指定 API 1 小时之内的请求量上限
    86400: 8000, // 指定 API 1 天之内的请求量上限
  },
  rate_computed: {
    // 根据之前的请求情况,结合客户配置计算出来的值(不小于客户配置)
    3600: 1000,
    86400: 8000,
  },
  strategy: {
    times_to_notify: 1, // 连续触发几次之后通知
    times_to_suspend: 3, // 连续触发几次之后暂停
    times_to_intercept: 12, // 连续触发几次之后拦截请求
  },
};
  1. 默认给所有客户开启最近 1 小时和最近 24 小时的限制。
  2. 速率控制以小时为单位([1, 24]

定时检查

  1. 定时执行
 5 10 15 20 25 30
35 40 45 50 55  0
  1. 查询过去 1 天有请求的客户清单,根据系统参数(可能还有业务上其他条件)跳过忽略检查客户

  2. 逐个客户查询最近 5 分钟内的请求量,并将 5 分钟数据统计到小时内
    然后逐个时间区间配置,判断总请求量是否超出预设值

end_min = (minute // 5) * 5
start_min = end_minute - 5
  1. 如果流量异常,按照指定策略触发相关事件

客户处理

PS:这个机制的目的是处理异常流量,如果正常的请求量上来了应该调整客户配置。

  1. 警告页面给出客户过去的请求情况,标出告警时间段的数据
  2. 让客户选择处理方案:
  3. 忽略并继续
  4. 清空暂停队列并继续
    可以查看下载受影响的请求信息
  5. 暂不处理
  6. 往后 24 小时之内,下一次触发告警的数量,提供一个默认值(当前请求量的 1.5 倍)
    另一种思路:如果客户选择继续请求,不用填下一次告警的数量,后面计算的时候直接跳过过去一段时间(比如 6 小时)的请求量。