[OpenBMC] LDAP 设定(三) - LDAPS(LDAP over TLS)

news/2024/10/4 15:31:39

终于到了最后一个部分 LDAPS, 这部分我们会依序介绍

TLS的原理(这边会补充密码学基础)
- 非对称式加密 vs 对称式加密
- 数位签章
- 数位凭证
- TLS 握手(hankshake)
如何产生凭证
上传凭证到LDAP Server
上传凭证到BMC
有可能会遇到的问题 (补充我遇到的问题)

TLS的原理

对称式加密 vs 非对称式加密

密码学中会根据加密和解密的金钥是否相同，将加密法分为非对称是加密和对称是加密，非对称就是指加解密的金钥不相同，对称式就是加解密金钥是同一把

对称式加密

加解密金钥同一把，我们这边可以举个例子，例如底下Alice 和 Bob都有同一把金钥 (key = 2)，他们有一个已知的加密演算法，将文字转乘ASCII 再乘上Key 就是密文(ciper text)，所以解密演算法就是将密文(ciper text)除上key 再转成文字就能的到原文了

比较有名的演算法就是DES，应用的话就像TLS 中，双方会透过某些方式产生一组彼此都知道的Session Key，之后所有讯息都会透过这把Session Key 来做加解密

非对称式加密

非对称式加密中会有两把金钥，分别是私钥(private key)和公钥(public key)，如以下的RSA范例(select p=3, q=11)，Alice 先产生一组金钥，她会将其中的公钥先给了Bob，Bob用手上的公钥来加密一段讯息给Alice，这段讯息只有Alice手上的私钥能解开

上面的范例应该能体会非对称是加密的神奇之处，先说缺点就是"加解密速度比对称式慢很多"，但它的神奇之处衍伸出两个很著名的应用

Key distribution (金钥分发)
Digital Signature (数位签章)

后来因为数位签章有中间人攻击的风险，Digital Certificate (数位凭证)就此诞生

Key distribution (金钥分发)

前面我们有提到TLS最后目的是透过某个方法来产生一组session key，来对之后传输的讯息做加密，这边的"方法"就是指"金钥分发"，如以下范例

Bob先产生一组Session Key, 用Alice给的公钥加密
Alice收到之后，用私钥解密得到session key
之后双方讯息都是session key做加密

Digital Signature (数位签章)

网路上的讯息要怎么证明传送者是谁呢?数位签章就有点像是个人签名，签署这份讯息是由你送出来的，如以下范例，如果Alice 在讯息后面加上它的数位签章，这样Bob就可以分辨哪个是由Alice传送过来的

底下是数位签章制作方法和原理

Alice 先将要传送的讯息M经过杂凑函数H产生H(M)
将H(M) 用私要加密，产生数位签章PA(H(M))
将数位签章PA(H(M))加到要传送的讯息M后面 (数位签章的长度是固定的)
Bob收到讯息后，将数位签章PA(H(M))和讯息M'分开
1. 将讯息M'经过杂凑函数H产生H(M')
2. 将数位签章PA(H(M))用公钥解密，取得H(M)
比对H(M)和H(M') 是否相等，如果相等，表示讯息没有被窜改，而且是Alice传送过来的

简化一下沟通流程，大概就是以下这样

但这样其实会有中间人攻击(Man-in-the-middle attack)的风险，就是Bob怎么能确定一开始拿到Alice的公钥是真的呢?

Digital Certificate (数位凭证)

为了解决这个问题，就出现了certificate authority (CA)，一个来颁发凭证来证明你手上拿到的公钥是没问题的单位，这边继续用alice和bob来举例

Alice 将她的个人基本讯息(CSR)和它的公钥拿给CA去签署(signed)
CA颁发凭证(Certificate)给Alice
1. 将Alice的讯息和公钥拿去做杂凑
2. 用CA自己的私钥加密做成数位签章
3. 然后加在Alice提供的讯息后面
Alice将凭证传送给Bob
Bob将凭证中的创建者(Issuer) xxCA解析出来，拿xxCA的公钥来看是否为这个真的是由其颁发，且凭证无损毁

TLS 握手(hankshake)

因为这篇文章是为了OpenBMC写的，所以这边我画了一张BMC在做LDAPS的时候hankshake的模拟图，

Client送hellp给Server端，有些会传送自己的凭证(这个看情况)
Server端收到Hello后，回传它的凭证
验证server 凭证是否合法，产生session key，连同之后这把key要搭配的对称加密演算法一起传给server

补充，在某些session key产生的演算法中，会用到Server的公钥(public key) 和client的私钥(private key)，所以这就是BMC要上传的LDAP凭证中，必须要包含private key的原因
确认Server那边讯息无误之后，所有讯息都会透过session key做加解密

如何产生凭证

这个部份OpenBMC已经有教学文件，How to configure the server TLS certificates for authentication

文章中有提到产生CSR，这部分可以透过OpenBMC的Create CSR功能来做，我这边是透过webUI，也可以透过Redfish，结果都一样的

分別做好signingReqClient.csr(LDAP), signingReqServer.csr(HTTPS)，就按照文章(How to configure the server TLS certificates for authentication

)的步骤继续完成：

openssl x509 -req -extensions my_ext_section -extfile myext-server.cnf -days 365 -in signingReqServer.csr -CA CA-cert.pem -CAkey CA-key.pem -CAcreateserial -out server-cert.pem

openssl x509 -req -extensions my_ext_section -extfile myext-server.cnf -days 365 -in signingReqServer.csr -CA CA-cert.pem -CAkey CA-key.pem -CAcreateserial -out server-cert.pem

但有几个地方需要注意，server certificate 的 cn 要填LDAPS server 的 hostname或IP，不知道LDAP server的hostname可以下已下指令

$ hostname
IRIS001

client certificate 的 cn 这边填Ldap 的 admin user

上传凭证到LDAP Server

产生一个设定档certinfo.ldif，填入刚刚产生的cert放置路徑

[POST] /redfish/v1/CertificateService/Actions/CertificateService.ReplaceCertificate
{"CertificateString": "-----BEGIN CERTIFICATE-----\nMIIDnTCCAoWgAwIBAgIUEZOkf69SVwaLa9l6Tp/gQMJioD4wDQYJKoZIhvcNAQEL\nBQAwXjELMAkGA1UEBhMCVFcxDzANBgNVBAgMBlRhaXdhbjEPMA0GA1UEBwwGVGFp\ncGVpMQ4wDAYDVQQKDAVqYWJpbDEMMAoGA1UECwwDYm1jMQ8wDQYDVQQDDAZUZXN0\nQ0EwHhcNMjExMDIxMDI1NzA4WhcNMjQwNzE3MDI1NzA4WjBeMQswCQYDVQQGEwJU\nVzEPMA0GA1UECAwGVGFpd2FuMQ8wDQYDVQQHDAZUYWlwZWkxDjAMBgNVBAoMBWph\nYmlsMQwwCgYDVQQLDANibWMxDzANBgNVBAMMBlRlc3RDQTCCASIwDQYJKoZIhvcN\nAQEBBQADggEPADCCAQoCggEBAKK1H9nIzIPHRRfVKPTmr1uwP8c23f/Oi+t1GVP3\nKijL/9KKDGwVf93F7wd1UWoEwWF5Hdfk84IYYe6skA5rh9RMWdQPcE9SVyDWkFTt\n/aMP/Ngl6l3zaqniW9uawa1ywXrEOdwRRpZwaizCVS0OxWaZn7mW9/aloqqTqf2q\nb4KX04x2Rdrnw3FWCnEpGaiaDc76bdeba0yg0/Lq1SFeYYuOYTcTIWOKB9BJyGhw\nD5G++QmwBUNK5s/ENzJZxnywX9yfYaARUURr19fo3pTCNMzBWOewt+PykCLTw0Wt\nmRvWpFwaIUgLaClrKkXh+9GcuEJUIRItpu06n/2nYtMAlhcCAwEAAaNTMFEwHQYD\nVR0OBBYEFPdM+K8hgEdU8/4rrFD5cjAjEgGDMB8GA1UdIwQYMBaAFPdM+K8hgEdU\n8/4rrFD5cjAjEgGDMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB\nAExEwJ1JD98pu5TW0aMi0L6mBMIayBaq68K9cJhB1xfA33buQIk54cOK7FXd9sBp\n+KY39vHNuYMp+J9tg/mqxS3d3/v5IcOvg96hRcHcPczWUmanNJuX29GZSoVkjMTF\n564EIfC6r0u9jbavlJsU5RuL7WSOgolvLa42PM44ShqfNIaKAi6hQzIVShhcG1UM\nulW1Ai6+Ih7yKeLVtkVTaDgSXODCTAPnXZI5qxWVWu/BU2CkllahdZ2Pna6mlvPv\n42po4X2MlBAGvy0ShwTxWA3QYqj1A87HpNjSqYLIwLWTE8S1+csWwgLGTMXpve0k\ncRgNpwA/3NURwmCvGs8yUyg=\n-----END CERTIFICATE-----\n","CertificateType": "PEM","CertificateUri": {"@odata.id": "/redfish/v1/Managers/bmc/Truststore/Certificates/1"}
}

LDAPS certificate 上传 client-cert.pem 和 client-key.pem 的合并档案

(因为产生Session Key的运算过程中会用到private key，但private key并不会传送给ldap server)，合并方法我是直接复制贴上，你也可以 echo client-cert.pem client-key.pem > Ldap.pem

最后上传给BMC

[POST]/redfish/v1/CertificateService/Actions/CertificateService.ReplaceCertificate
{"CertificateString": "-----BEGIN CERTIFICATE-----\nMIIDrTCCApWgAwIBAgIUPJjMDmZ/Kn44kdLol7NaAoDyFAYwDQYJKoZIhvcNAQEL\nBQAwXjELMAkGA1UEBhMCVFcxDzANBgNVBAgMBlRhaXdhbjEPMA0GA1UEBwwGVGFp\ncGVpMQ4wDAYDVQQKDAVqYWJpbDEMMAoGA1UECwwDYm1jMQ8wDQYDVQQDDAZUZXN0\nQ0EwHhcNMjExMDIxMDI1ODIwWhcNMjIxMDIxMDI1ODIwWjBdMQswCQYDVQQGEwJU\nVzEPMA0GA1UECAwGVGFpd2FuMQ8wDQYDVQQHDAZUYWlwZWkxDjAMBgNVBAoMBWph\nYmlsMQwwCgYDVQQLDANibWMxDjAMBgNVBAMMBWFkbWluMIIBIjANBgkqhkiG9w0B\nAQEFAAOCAQ8AMIIBCgKCAQEAhpU78FV7loXU7uwT2fgMqVNrVac6OA80SoOxwCWO\nOR8WL3Z7R51ZIBgDe2WcC1mQGNO8ymt0YvcZInWJGPKlrSSIxGTcgPh36ZUx8WZw\nDjC05LaOoyPa/av/snkmsWHKCWd4tXALltb7fs+agaNPThBE8gqI7L6QvBExQgZf\nRaBLPZ6lizyb+ovEYOzY/wPh4VCYSCz+41eOEHxSno6hN4X8h7dGJwYRTMAt+Dys\nrCBIpTvKSJvRkVhh8SgEr4EV+izSEelbCMJZg3uv2aeabxpWYK7x4L4r8OWfQi2P\ndW5SkAUFjg6/tf16ZaOFUY4Ro3NxA1D49nxJhkLP8aBU+wIDAQABo2QwYjALBgNV\nHQ8EBAMCA4gwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHwYDVR0jBBgwFoAU90z4ryGA\nR1Tz/iusUPlyMCMSAYMwHQYDVR0OBBYEFMlmWZNjqmmMNFfGJRXvEfxDCL5jMA0G\nCSqGSIb3DQEBCwUAA4IBAQCYBY3cY78GmOqTbKByGXBwar5Nb7O6xYeQb/f3fJAJ\nJYLI5jZnKWbixo4P6jl34+21WGxivT2GxFC4m9qdB8YBkbhvtk5dpMynoGmKrC9d\nn+OamBUuHC8yw6zrGywauD1XLnwy+eUULg51gOFvvM4XVqg44pRwzGwnzvGSmGDq\n2vAD5KWglcJ9d0nMLRlCW70bZbgG46ifRJvDxATp69HL2aS1tpwA2xJz1akkCzn8\nHzfZD02D1xIpAOTIf5pevZakhBsdZKiJeobkyoVCI1/L3mJX/4PFIyxbVr5AchO6\nQXmVeNx5LQ09afIVI/FlQcf4EWtza/E8DAl4vO31NuFA\n-----END CERTIFICATE-----\n-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCGlTvwVXuWhdTu\n7BPZ+AypU2tVpzo4DzRKg7HAJY45HxYvdntHnVkgGAN7ZZwLWZAY07zKa3Ri9xki\ndYkY8qWtJIjEZNyA+HfplTHxZnAOMLTkto6jI9r9q/+yeSaxYcoJZ3i1cAuW1vt+\nz5qBo09OEETyCojsvpC8ETFCBl9FoEs9nqWLPJv6i8Rg7Nj/A+HhUJhILP7jV44Q\nfFKejqE3hfyHt0YnBhFMwC34PKysIEilO8pIm9GRWGHxKASvgRX6LNIR6VsIwlmD\ne6/Zp5pvGlZgrvHgvivw5Z9CLY91blKQBQWODr+1/Xplo4VRjhGjc3EDUPj2fEmG\nQs/xoFT7AgMBAAECggEACYYwkMmdCesu15TU/D5Lkxc6tWm0ux0I6Ygzpd/0zS/r\nXTnNFFxtg+Qju4Po1erJ5k2a3jLsZ21lqAki6pL9cURwjIBcOQ7lkGcpn0rfojlz\nMFnQcwvbwe/Zgc6E70MbcoftaQNk1Ef+G1NjGCX5BSUJLS+TPqZnO+I/TcvvN/S7\ncL+jP+9mTZ+U4ZsuGtW7T3yw3JpgAZ2jdNt5VB4sXilk1246btl/7kYeJqYEeK/K\nsLYJ+t4JhjBIq1Wpeblj2YHLfpSKxCdooBFiO+Pks5misk4Q1Y7ikvgMAKfKbmnm\nyrm9MN4yZ9ALKQAIBjz5YDjmvK8lbLg2xpJmoe30MQKBgQC9L9efhFTX2VWdpE+D\ngvVty3a8ZxvasG4PN9HCFlRrD+wfhAkU7DIJM6tfZoWkCo9txirBB2NTTUwIT/i8\n6Jb9ctZMdfHx0520vwxHdo3AduqE/z/RUk7YE3OWcM6AcZ7OxbqW3vkkaN15z5nG\nTORpFiKDW1Kv1lOEyxZ3HLw+sQKBgQC2HLc7u88zvah94/RyZzBtVthwpIW+Ow+6\nL/bZNbMmKh8n+kwKLXJZUjQfoY8en664LAWxxsvuOHerPmcxkwlga64ipNTZrjRL\n2aBc2wN0whY+ytaOCW7wF7MCxkGvYfFQyv2nZ6JSBM3Mss0KNZZNNbL79ZlTAGC4\nBiQLWSZxawKBgDpcXN73mpivkcq8mk7Oglmpb2p1QFF5JaqKJKoD62zPj561Q3vx\n1Qmjp9UZMlbFbzOE80FyvwA+kxrpWKkl8xYia9tQcx+PkVHlsasF9nqN9JCskQpI\nosvjTD/3cqyK4FuXAZVzGVZTByeBlEVpCPkl++WbsWlO65rGb5q1AZkxAoGAWsS7\nS2mTn+1jAsRQvYjTKVxE6vgFtUhI0XtApQjP7zDFcK6fod7/BKglVLK43AGpGyDO\nAcrdMDIy60ZiNuJbpRRmqdvQP2NFq5ygAkgjU9m9LrT49bib881MKxDYAmtl1Ogo\nP302+Xxtex6Pdgw5iug9+rlyH12r120wH/viXlsCgYBtEPGxwQuI7TSHvRi1Z6W0\nKPlEDRFidOWHRlPoqfUegCLgwIHvo6Jo5wDKRtmfDpbZovdDMvuvOM4KID5IeQas\nZkdKqtq2Ik15Tr2HRSiriktZYgO49gVHrfN59xTT1n2XIqBSvXQF3EOJ+7kXutzx\nzAFxrjvZ/QcxoBvCv/AqlA==\n-----END PRIVATE KEY-----\n","CertificateType": "PEM","CertificateUri": {"@odata.id": "/redfish/v1/AccountService/LDAP/Certificates/1"}
}