Triển khai Netty đơn giản của máy chủ https sử dụng javax.net.ssl, với chứng chỉ tự ký. Máy chủ khởi động và sau đó yêu cầu được thực hiện bằng cách sử dụng DHC by Restlet. Về phía server tôi nhận được:javax.net.ssl, https khách hàng và close_notify
io.netty.handler.ssl.SslHandler setHandshakeFailure CẢNH BÁO: SSLEngine.closeInbound() huy động một ngoại lệ do kết nối khép kín. javax.net.ssl.SSLException: Inbound đóng trước khi nhận được close_notify của peer: có thể cắt ngắn tấn công? tại sun.security.ssl.Alerts.getSSLException (Nguồn không xác định) tại sun.security.ssl.SSLEngineImpl.fatal (Nguồn không xác định) lúc sun.security.ssl.SSLEngineImpl.fatal (Unknown Source) lúc mặt trời. security.ssl.SSLEngineImpl.closeInbound (Nguồn không xác định) tại io.netty.handler.ssl.SslHandler.setHandshakeFailure (SslHandler.java:905) tại io.netty.handler.ssl.SslHandler.channelInactive (SslHandler.java WEBC76) tại io.netty.channel.DefaultChannelHandlerContext.invokeChannelInactive (DefaultChannelHandlerContext.java:819) tại io.netty.channel.DefaultChannelHandlerContext.access $ 1300 (DefaultChannelHandlerContext.java:38) tại io.netty.channel.DefaultChannelHandlerContext $ 5.run (DefaultChannelHandlerContext.j ava: 808) tại io.netty.channel.SingleThreadEventExecutor.runAllTasks (SingleThreadEventExecutor.java:259) tại io.netty.channel.nio.NioEventLoop.run (NioEventLoop.java:305) tại io.netty.channel. SingleThreadEventExecutor $ 2.run (SingleThreadEventExecutor.java:110) tại java.lang.Thread.run (Unknown Source)
Và trên các mặt hàng:
Không phản ứng. Chứng chỉ có hợp lệ không? Bấm vào đây để kiểm tra.
Phát hành cùng một yêu cầu tại thanh địa chỉ của Chrome, ngoại trừ cùng một phía máy chủ. Phát hành tương tự tại thanh địa chỉ của Firefox, ngoại lệ tương tự trong khi Firefox hiển thị trang cảnh báo của nó về chứng chỉ không phải từ một CA đáng tin cậy. Ngoại lệ này có vẻ rất chung chung và không trực tiếp cho biết trạng thái của giao thức là. Có nghĩa là 3 khách hàng này (Chrome, Firefox, DHC by Restlet), không phát giao thức độc đáo và chỉ biến mất trên máy chủ thay vì gửi một close_notify? hoặc là một hành vi phía máy khách được ủy nhiệm bởi SSL RFC hay chỉ là một thiết kế phía máy khách được định hướng bảo mật?
Dường như tất cả khách hàng tôi đã thử chỉ bỏ qua việc gửi một thông báo đóng. Có lẽ nó là tốt cho khách hàng chỉ cần thả ra ngay lập tức, mặc dù rời khỏi máy chủ một chút bối rối như những gì có thể là lý do chi tiết ... – matanster
Hi Matt. Tôi đang thực hiện yêu cầu https từ Dev HTTP Client và có cùng tình huống ở phía khách hàng. Làm thế nào bạn quản lý nó? –
@AntonioAcevedo, có vẻ như các ứng dụng khách thường hoạt động theo cách sau khi kết nối với chứng chỉ không đáng tin cậy - chúng đóng kết nối và nhắc người dùng. Vì vậy, tất cả các máy chủ nhìn thấy là khách hàng biến mất trên chúng, nhưng khách hàng không thông báo cho máy chủ về lý do của nó. Điều này làm cho cảm giác an toàn khôn ngoan từ quan điểm của khách hàng (phân phối số lượng thông tin ít nhất khi một vấn đề bảo mật cho một bên thứ 2 là một thực hành tốt). Vì vậy, tình trạng này không yêu cầu 'giải quyết' nhưng chỉ chấp nhận nó như là một. – matanster