为 SSL/TLS 的 http 标头添加更多参数
据我了解，https 是 http 加 SSL/TLS。
如果我想为 header 添加 3 个参数，我需要做什么？ 我在 Mozilla 的 NSS 中找到了一个文件 - ssl3ext.c，但我不明白它，也不知道如何开始。需要你们提供线索..
这是关于 SSL/TLS 扩展的吗？但它要复杂得多，对吧？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
RFC 3546“传输层安全 (TLS) 扩展”是唯一定义的添加方式SSL/TLS 握手的附加参数。
您可以将您的分机添加到 Client Hello 消息中。如果服务器识别到它，它可以在 Server Hello 消息上使用相应的扩展进行响应。但是，除非有请求，否则服务器无法发送它。
它与 HTTP 无关。 SSL/TLS 握手在 HTTP 开始之前就已经结束。
请参阅 RFC 3546 了解扩展格式。 IANA 管理分机号码。
http://www.iana.org/assignments/tls-extensiontype-values/< /a>
请注意，没有可供您使用的“实验”范围。恕我直言，您在自己的港口上所做的事情是您自己的事，但请注意将来发生冲突的可能性。
如果您发送一些 SSLv3 和较旧的 TLS 1.0 服务器不喜欢的扩展，它们就会挂断您的电话。主要网络浏览器实现后备重新连接逻辑，无需扩展。
如果您的分机遵循 RFC 3546 中定义的分机通用格式，则您违反的唯一（现代）标准是您没有使用 IANA 认可的分机 ID 号。如果您的扩展通常有用，您应该强烈考虑将其提交以进行正式标准化。
RFC 3546 'Transport Layer Security (TLS) Extensions' is the only defined way to add additional parameters to the SSL/TLS handshake.
You can add your extension to the Client Hello message. If the server recognizes it, it can respond with a corresponding extension on the Server Hello message. The server cannot send it unless it was requested, however.
It has nothing to do with HTTP. The SSL/TLS handshake is over before HTTP even begins.
Look at RFC 3546 for the extension format. The IANA manages the extension numbers.
http://www.iana.org/assignments/tls-extensiontype-values/
Note that there is no 'experimental' range for you to use. IMHO what you do over your own ports is your own business, but be aware of the possibility of conflict in the future.
Some SSLv3 and older TLS 1.0 servers will hang up on you if you send an extension they don't like. Major web browsers implement fallback reconnect logic without extensions.
If your extension follows the general format for extensions defined in RFC 3546, the only (modern) standard you are breaking is that you are not using an IANA-blessed extension ID number. If your extension is generally useful, you should strongly consider submitting it for formal standardization.
您可以根据需要添加任意数量的 HTTP 标头参数，而无需担心 SSL。如果您想要修改 SSL 握手，您应该在连接两端都有 SSL 库的源代码。
我不确定你想在这里做什么。您可以修改 ClientHandshake 以包含更多/客户密码套件。您还可以定义自定义内容类型。当前，TLS记录中的第一个字节确定了内容类型，如下所示：
取决于您尝试做的事情，您可能会通过将自定义警报添加到警报协议。警报可以随时向任一方向发送。
自定义协议将打破标准，尽管您可以在不更改协议的情况下执行添加密码套件之类的操作。在客户端证书和服务器证书之间，该协议通常具有大多数人进行身份验证和加密所需的一切。
You can add as many HTTP header parameters as you like, without concern for SSL. If you want to modify the SSL handshake, you should have the source to your SSL libraries on both sides of the connection.
I'm not sure what your trying to do here though. You could modify the ClientHandshake to include more/customer cipher suites. You could also define a custom content type. Currently the first byte in a TLS record determines the content type, which are as follows:
Depending on what you are trying to do, you may be well served by adding a custom alert to the Alert Protocol. Alerts can be sent at any time, in either direction.
Customizing the protocol will break the standard, though you can do things like add cipher suites without changing the protocol. Between client certs and server certs, the protocol generally has everything most people need for authentication and encryption.
SSL/TLS 是传输层。首先进行协商，然后 HTTP 对其进行“讨论”。要添加更多 HTTP 标头参数，您的操作与平常完全相同。
（完全清楚 - HTTPS 是 TLS/SSL“之上”的 HTTP。首先建立 TLS/SSL 连接，然后 HTTP 使用它，就像使用未加密的传输一样）。
SSL/TLS is a transport layer. It's negotiated first, and then HTTP talks "over" it. To add more HTTP header parameters you do exactly the same as you would normally.
(to be completely clear - HTTPS is HTTP "on top" of TLS/SSL. The TLS/SSL connection is made first and then HTTP uses it just like it would use an unencrypted transport).