RFC2818--HTTPS/TLS 翻译

本文详细介绍了HTTPS协议的工作原理,包括连接初始化过程、连接关闭机制、端口号及URI格式规范等内容。此外,还深入探讨了服务器与客户端的认证机制,帮助读者理解HTTPS的安全保障措施。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

rfc2818原文原文连接

翻译


RFC818文档中对HTTPS的描述如下:

连接初始化--

运行HTTP的客户端也是运行TLS的客户端。这个客户端需要在合适的端口向服务器发送一个连接请求,然后发送TLS clienthello 来开始一个TLS握手。当TLS握手结束后,客户端会发起首个HTTP请求。所有的HTTP数据必须以TLS “applicationdata”的形式发送。正常的HTTP行为,包含保持连接的行为,也要这么做。(以TLS “application data“的形式发送)。

 

文档中还描述了HTTPS连接关闭时客户端和服务器端的行为、端口号、URI的格式,端系统认证(包含服务器的认证、客户端的认证)

 

连接的关闭—

TLS 提供了安全连接关闭的机制。当一个有效的关闭提醒被收到之后,可以如下来实现—这条连接上将不会有进一步的信息被接收。TLS的实现要求,在关闭连接之前连接双方必须要交换关闭提醒(closure alerts)。在TLS的实现中,一方可以在发送了关闭提醒之后直接关闭连接而不等待对方的关闭提醒发送,从而产生一个“不完全关闭“。应当注意,这样实现可以重用session(连接)。这样实现要求用户程序知道自己所需的信息已经全被收到(典型的如,通过检查HTTP消息的边界)。

在rfc2246中特别指出,任何在关闭连接之前没有收到有效关闭提醒(valid closure alert)的实现方式,禁止重用连接。提前关闭不会对已经传输的数据产生安全问题,但是意味着随后的数据也许会被截断。因为TLS是不检查HTTP请求/应答报文的边界的。所以检查HTTP数据是在在一个报文段之内被截断还是在报文段之间被截断是很重要的(通常是通过content-length头部来检查)。

       客户端行为—

       因为HTTP使用连接关闭来标志服务器端数据的传输结束,所以客户端必须将任何连接提前关闭看成是错误并且认为已收到的数据是被截断的、不完整的。然而在有些情况下,HTTP洗液允许客户端检查是否发生了截断,容忍传输完成情况下的连接提前关闭的错误。

       两种情况要特别注意:

       HTTP响应报文没有Content-Length 头部。在这种情况下(容忍提前关闭连接的错误),数据长度有连接中断来决定,此时如果攻击者发来消息,客户端并不知道。

       包含有效长度的HTTP响应响应报文在所有数据被读进之前送到且关闭连接。无法区分是服务器计算错误还是连接被劫持中断。

对于上面的rule有个例外。当遇到了提前终止连接,客户端应当将其看成所有请求已经发送,且接收了尽可能多的数据。

       客户端检查一个不完整的关闭,并应该优雅地(gracefully)恢复。它要重新开始被意外中断的对话。

       客户端必须在关闭连接之前发送一个关闭提醒。不准备接收更多的数据的客户端可以选择不等待服务端发送关闭提醒,而是可以直接关闭连接。从而产生一个不完整的关闭(客户端关闭了连接,而服务端依旧单方面维护着连接)。

       服务器端行为—

       RFC2616允许HTTP客户端在任何时候关闭连接,要求服务器端优雅地(gracefully)恢复连接。特别地,服务器端应该准备遇到客户端意外的终端(客户端不等待服务端发关闭提醒就关闭连接)。客户端可以决定服务器什么时候终止数据传输。服务器端应当时刻准备恢复被客户端意外关闭的的对话(连接)。

       实现的note:在HTTP实现中并不使用持续连接,服务端应当能够通过关闭连接来提示数据的终止。当发送content-length,客户端也许已经发送了关闭提醒且关闭了连接。

       服务器必须要在关闭连接之前提起和客户端交换关闭提醒。服务端也可以(MAY)在发完关闭提醒之后关闭连接,从而在客户端留下了单方面的连接。

 

端口号—

HTTP服务器期望收到来自客户端的首个数据是Request-Line production。然而,TLS 服务器(HTTPS 服务器)期望收到来自客户端的首个数据是ClientHello。从概念上说,常见的做法是将HTTPS/TLS运行在不同的端口上,以便于区分不同的协议。当HTTPS/TLS 被运行在TCP/IP连接上,默认端口好是443. 当然,HTTPS/TLS也可以运行在其他的端口号上。TLS只是假设在此端口上有一个可靠的面向连接的数据流。

URI Format—

HTTPS/TLS 和HTTPSURIs不同之处在于将HTTP的URI中的http改成了https

端系统的认证—

       服务器的认证—

       HTTPS/TLS请求通过解引用URI来产生。因此,客户端是知道服务器的hostname的。如果客户端知道服务器的hostname,客户端必须在服务器的证书信息里面检查当前获得的服务器的身份,来防止中间人攻击。

       如果客户端有想要访问的服务器有额外的信息,检查hostname的工作可以忽略(例如,访问的服务器的地址和hostname是动态变化的,但是客户端知道服务器早晚会提供证书的)。在这种情况下,缩小可接受证书的范围是很重要的,以此防止中间人攻击。特殊情况下,客户端可以忽略服务器身份,但是这样做会让连接面临被攻击的风险。

       如果hostname和证书中的身份信息不匹配,客户端需要通知客户是否继续或者关闭连接返回一个badcertificates error。默认处理的客户端需要将错误记录在audit 日志上并应该关掉连接返回错误。

       注意到,很多情况下URI本身来自不可信的来源,以上的检查无法提供避免攻击的保护。如网页中的连接会被替换为不使用HTTPS/TLS,点击时会受到中间人的攻击。

       客户端认证—

       典型情况,服务器对客户端的身份信息没有额外的要求,所以检验身份是不必要的。

 


<think>好的,我现在需要帮助用户确认Apache Tomcat 11.0.5的启动日志是否正常,并验证其配置是否与Java 11 OpenJDK兼容。首先,我需要考虑用户可能的需求和潜在问题,然后逐步分析可能的解决步骤。 首先,用户提到的是Tomcat 11.0.5和Java 11 OpenJDK的组合。Tomcat 11支持Java 8及更高版本,而Java 11是LTS版本,因此理论上应该是兼容的。但用户可能遇到启动失败或配置错误的问题,需要检查日志和配置。 第一步,用户需要查看Tomcat的启动日志。通常日志位于Tomcat安装目录下的logs文件夹中,尤其是catalina.out或catalina.yyyy-mm-dd.log文件。用户需要检查日志中的错误信息,比如ClassNotFoundException、NoSuchMethodError等,这些可能表明版本不兼容或库缺失。 接下来,验证Java版本是否正确。用户应确认系统默认的Java版本是否为OpenJDK 11,可以通过运行java -version命令来检查。如果版本不符,可能需要更新JAVA_HOME环境变量,指向正确的JDK路径。在Tomcat的启动脚本(如catalina.sh或setenv.sh)中,也应确保JAVA_HOME正确设置。 然后是配置文件检查。Tomcat的主要配置文件包括server.xml、web.xml和context.xml。用户需要确认server.xml中的连接器配置(如HTTP端口8080是否正确,是否有冲突),以及是否启用了SSL或其他特性。同时,检查web.xml中的Servlet版本是否符合Tomcat 11的要求,Tomcat 11对应的是Servlet 5.0规范。此外,context.xml中的资源链接是否正确,比如数据库连接池配置是否存在错误。 内存配置也是关键。如果应用需要更多内存,用户可能需要调整JVM参数,如-Xms和-Xmx,在catalina.sh或setenv.sh中设置。例如,JAVA_OPTS="-Xms512m -Xmx1024m"。如果用户的应用有特殊需求,调整这些参数可以避免内存不足的问题。 安全配置方面,用户需要确保没有使用已过时的协议或密码,特别是在生产环境中。检查server.xml中的SSL配置,确保使用TLS 1.2或更高版本,避免使用弱加密算法。 可能遇到的问题包括端口冲突,比如8080端口被其他应用占用,导致Tomcat启动失败。用户可以通过netstat或lsof命令检查端口使用情况。类冲突或依赖问题也是常见问题,尤其是当应用使用了与Tomcat内置库冲突的第三方库时,需要检查WEB-INF/lib目录下的JAR文件。 日志分析示例:如果日志中出现“The valid characters are defined in RFC 7230 and RFC 3986”,这可能是因为URL中包含非法字符,需要检查应用代码或进行编码处理。另外,“Address already in use”表明端口被占用,需更换端口或终止占用进程。 用户可能还想知道如何启用更详细的日志记录,可以通过修改logging.properties文件,调整日志级别为FINE或FINEST,但需注意这会产生大量日志,建议仅在调试时使用。 最后,生成相关问题,帮助用户深入理解Tomcat配置和故障排除方法,比如如何配置虚拟主机、优化性能或解决内存泄漏问题。</think>### Apache Tomcat 11.0.5启动日志检查与配置验证(Java 11 OpenJDK) #### 一、启动日志检查步骤 1. **定位日志文件** Tomcat日志默认位于`logs`目录下,重点关注以下文件: - `catalina.out`(启动过程的核心输出) - `catalina.yyyy-mm-dd.log`(按日期分割的日志) - `localhost.yyyy-mm-dd.log`(应用部署相关日志) 2. **关键日志标识符** - **正常启动标志**: ```text INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [X] milliseconds ``` 若出现此信息,表示Tomcat已成功启动[^1]。 - **常见错误类型**: - **Java版本不兼容**: ```text Unsupported major.minor version 55.0 ``` 表示编译环境JDK版本高于运行环境(Tomcat 11需Java 11+)[^2]。 - **端口冲突**: ```text java.net.BindException: Address already in use ``` 需检查`server.xml`中`<Connector port="8080">`的端口配置。 #### 二、Java 11 OpenJDK配置验证 1. **确认Java版本** 执行命令: ```bash java -version ``` 输出应为: ```text openjdk version "11.0.15" 2022-04-19 ``` 2. **设置`JAVA_HOME`环境变量** 在Tomcat启动脚本(如`catalina.sh`或`setenv.sh`)中添加: ```bash export JAVA_HOME=/usr/lib/jvm/java-11-openjdk export PATH=$JAVA_HOME/bin:$PATH ``` #### 三、关键配置文件检查 1. **`server.xml`验证** - 检查连接器配置(示例): ```xml <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> ``` 确保端口未被占用,SSL配置正确(如使用`keystoreFile`)。 2. **`web.xml`兼容性** Tomcat 11对应Servlet 5.0规范,需确认`web.xml`头部声明: ```xml <web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd" version="5.0"> ``` 3. **内存配置调整** 在`setenv.sh`中设置JVM参数: ```bash export JAVA_OPTS="-Xms512m -Xmx2048m -XX:MaxMetaspaceSize=256m" ``` #### 四、典型问题解决示例 **问题**:日志中出现`SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[AJP/1.3-8009]]` **原因**:AJP协议端口冲突或配置错误。 **解决**:在`server.xml`中注释掉AJP连接器: ```xml <!-- <Connector protocol="AJP/1.3" address="::1" port="8009" redirectPort="8443" /> --> ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值