SSL 泛洪故障排除

发布于 2024-08-17 08:37:28 字数 330 浏览 2 评论 0原文

用户通过 https 连接到我们的网络服务器,并在使用我们的服务期间保持安全连接。典型的用户会话将与服务器建立少量连接(一个或两个)。

我们正在尝试找出极少数的例外情况。特定用户会间歇性地建立数百个连接。当我们碰巧发现问题时,我们可以看到 SSL 握手的交换,从服务器的角度来看,一切似乎都井然有序。然而我们从未观察到有效负载 - 客户端而是连接到新端口并发起新的握手。

我们无权访问客户端,也无法观察连接那一端的行为。我们也没有可以重现该问题的本地场景。

我们相信(尽管尚未证实)用户代理直接连接到我们的服务器,而不是通过代理。

有人认识这些症状吗?谁能建议进一步确定问题的步骤?

Users connect to our webserver via https, and stay on a secured connection throughout their use of our service. A typical user session will establish a small handful of connections to the server (one or two).

There are a very small number of exceptions we are trying to track down. Particular users will intermittently have handfuls of hundreds of connections established. When we happen to catch the problem in the act, we can see the exchange of the SSL handshake, and from the perspective of the server, all appears to be in order. Yet we never observe a payload - the client instead connects on a new port and initiates a new handshake.

We do not have access to the client, and cannot observe the behavior from that side of the connection. Nor do we have a local scenario that can reproduce the problem.

It is our belief (though not confirmed) that the user agent is connecting to our server directly, and not through a proxy.

Does anybody recognize these symptoms? Can anyone suggest steps to further identify the problem?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

动听の歌 2024-08-24 08:37:28

除了多次重复请求之外,您还能看到此流量的任何模式吗?

例如,请求是否来自相同的 IP 范围?可能是搜索引擎或其他蜘蛛,或者可能来自您通常没有用户的国家/地区,可能表明某种奇怪的僵尸网络或至少是您可以阻止的东西?

这些恶意请求是否总是协商使用特定的密码套件,可能表明客户端软件?
如果更改可用于协商的可用密码套件,会有什么不同吗?

您正在使用什么服务器软件?您的网络中是否存在可能会丢弃对用户的某些响应的防火墙?

Are there any patterns you can see to this traffic, aside from making many repeated requests?

For example, do the requests come from the same IP ranges? Possibly search engines or other spiders, or maybe from countries that you normally don't get users from, possibly indicating some sort of weird botnet or at least something you could block?

Do these rogue requests always negotiate to use a particular cipher suite, potentially indicating the client software?
Does it make any difference if you change the available cipher suites available for negotiation?

What server software are you using, and are there any firewalls within your network that could potentially be dropping some responses to the user?

沉默的熊 2024-08-24 08:37:28

这可能不是你的情况,但我想我提到过。

我看到 chrome (12.0.742.60 beta) 用 https 连接淹没我的服务器,为正在服务的单个静态图片提供了大约六个或更多的连接......就好像它有一个优化来建立连接,并等待准备好的 https 握手用于发送请求,然后在提供页面(文件)后将其全部关闭。

在纯 http 上,我只看到两个连接(favicon.ico 还多了一个)。

this is probably not your situation, but i thought i mention it.

i'm seeing chrome (12.0.742.60 beta) flooding my server with https connections, some half a dozen or more connections for a single static picture being served... as if it had an optimization to build up connections with ready https handshakes waiting for requests to send, and then after the page (file) has been served it closes them all.

on plain http i see only two connections (one extra for favicon.ico).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文