问题标签 [poodle-attack]

我有一个与 API 通信的网站，由于 POODLE 等各种安全漏洞，该网站会关闭使用低于 TLS 1.1 的任何内容的连接。

该网站是使用 .NET Framework 4.0（不兼容 TLS 1.1 或更高版本）编译的，并且无法升级到更高的 .NET Framework 版本，因为它驻留在 Windows 2003 服务器上 -此处的兼容性列表

是否有任何好的、最好是免费的第三方库可用于强制 .NET 4.0（或更低版本）应用程序从 C# 以编程方式使用 TLS 1.1 或 TLS 1.2？

我找到了这个 Windows 注册表解决方案，但这不是 C# 解决方案；

要在 .NET Framework 4.0 中默认启用 TLS 1.2，可以将以下两个注册表项中的 SchUseStrongCrypto DWORD 值设置为 1，如果它们不存在则创建它们：

• “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319”

• “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319”

我想构建一个不能正确检查 AES CBC 填充的特殊版本的 OpenSSL。我正在研究 OpenSSL 1.0.2g 的来源。我应该在源目录中查找哪些文件？

我正在尝试设置 POODLE TLS 易受攻击的服务器，使用针对未正确检查填充的特殊版本的 OpenSSL 编译的 Apache/Nginx。

I'm wondering which changes from SSL 3.0 to TLS 1.0 exactly fixed the POODLE Attack. The Base for this Attack is the Messageblocks M1||MAC||PAD, so a whole Block is used for MAC and Padding.

I have the Idea, that it doesn't work anymore (without downgrading) cause in TLS 1.0 if the last Block is Padding it is 0x101010... (With block size of 16) and not 0xXX...XX10 (XX=Random), so it's a lot more Heavy to guess 16 Bytes directly instead of only the last Byte.

But are there any other security parameters that fixed this problem or did I mentioned it right? Like is the end of the Messages not ||MAC||PAD anymore? Or is the PAD maybe signed or something like that?

Regards Julian

我正在尝试收集有关sslv3连接的流量，以及使用curl. 要启用sslv3连接，
以下是版本列表：
openssl 1.02k
curl 7.21
ubuntu 14.04
但是，当我尝试连接时，它会提示我“阻止列表”。但是应该解决这个问题才能成功连接吗？

url 用 测试过testssl，它很容易受到贵宾犬的攻击，因此连接它sslv3应该不是问题