嗯...这里有很多可能出错的地方...
一方面,SSL 服务器证书只能保护您免受正常窃听,如果操作正确,还可以保护服务器的身份。它不能确定客户是谁。 (我假设您正在对客户端上的服务器证书进行适当的安全检查)。
但这不会告诉服务器有关客户端的任何信息。为此,您还需要分配一个客户端证书并在服务器上对其进行验证,即使如此,如果没有正确完成,此解决方案仍然容易受到man in the middle attacks 的攻击。
回到您的配置。如果您的服务器证书验证未正确完成,则有人不仅可以窃听而且还可以注入/修改您的通信通道上的信息(因为您没有对消息本身执行任何签名以验证它没有被修改)。
IP 过滤器很弱,因为大多数机构都有一些NAT 或Proxy 配置供外部访问。因此,通过同一节点进行外部访问的 pc 将显示相同的 IP。所以不需要“欺骗”......你只需要破坏任何内部机器......就像秘书的机器(咯咯笑)......然后从那里提出请求。
我不确定 IP 欺骗是否是有效的攻击,在这种情况下,攻击者会在客户端机器上造成拒绝服务,然后尝试连接到服务器伪造数据包并利用被欺骗的客户端无法响应并首先发送数据包以终止连接。
这意味着猜测包裹序列号,这在现在很难,但并非不可能。从那里,攻击者可以盲目地注入他需要的任何消息,但在这种情况下,因为连接不是纯 html,而是涉及交换密钥等信息的 ssl 流,并且鉴于攻击者看不到,因为注入是盲目完成的(至少除非它在同一个子网中并且可以嗅探数据包)......我怀疑它可能。
无论如何...推荐的配置。
1
- 在客户端验证的服务器 SSL 证书。
- 在服务器上进行验证的客户端 SSL 证书。
- 消息的某种校验和,除了 GUID 令牌.. 我建议每次为每个会话客户端生成。
(不要忘记在加密存储 pkcs12 等上安全地分发此证书,否则这种方法容易受到中间人攻击)
2
- 使用 WS-Security 扩展 Web 服务肥皂消息,并使用客户端和服务器签名/加密与客户端和服务器证书,并使用时间戳服务。
您仍然可以 ip 绑定连接...但没有必要...而且它仍然很弱。
在旁注中,Kevin Mitnick 在1994 中使用 IP 欺骗攻击 Shimomura...所以这是可能的而且不是非常困难。我敢打赌,根据您的服务器操作系统版本,已经有一些工具可以自动化大部分过程。
我很想听听别人的想法。希望这会有所帮助。