如果我们考虑中间人攻击; 如果使用对称密钥,是否会发生此类攻击？
我有一个Android(4.2)应用程序,它使用https与Web服务进行通信.我想调试/记录每个出去的https.我有fiddler和wireshark来调试它们,但一切看起来都是加密的.可以使用模拟器和fiddler/wireshark设置中间人攻击来解码和显示http url及其参数吗？
我正在尝试分析应用程序发送的信息,所以我设置了Charles,但令我惊讶的是没有注销.
在反编译应用程序后,我发现它不使用简单的REST调用,而是使用名为gRPC的库.
有没有一个好的工具可以让我看到从应用程序发送的内容？
似乎SSH设计师在中间攻击中非常关心人.
他们的做法是,以节省服务器的公钥指纹在你连接到服务器的第一时间(希望用户没有在第一时间从中毒的网络连接,例如,如果他在一个病毒电脑).然后,用户在下次连接到此服务器时使用指纹验证服务器的公钥.
在实践中,我发现许多用户只是忽略了有关无法比拟的指纹的警告,并假设它是由于服务器重新安装.只是MITM攻击是如此难以进行和罕见,你永远不会担心它.此外,很多时候用户想要使用ssh许多不同的计算机,并且他不会费心将所有指纹导入到他可能想要使用的任何计算机SSH上(嘿,你能看看为什么我的网站出现故障,我感到恐慌!我不在办公室,我会去最近的网吧看看).
公平地说,可以使用DNSSEC和使用DNS服务器作为CA.但是我从未见过在实践中使用过的东西.无论如何,它不是协议的强制性部分.
多年来我一直认为没有预先设定的秘密就无法避免MITM,但我最近一直在阅读Bruce Schneir的优秀"实用密码学",在那里他提到了互锁协议.
现在,Mallory必须在收到Alice的一半消息之后,在协议的第(3)步中向Bob发送一些内容,即使他无法解密它,直到他从(5)中的Alice获得所有内容.他必须给Bob制作一条消息,Bob可能会注意到他正在制作他ls的主目录之后.
为什么不SSH使用这样的方案？它似乎真的符合它的目标.它不需要任何其他实体,它使MITM攻击变得更加困难.
这是固有的吗？我对这个问题的理解存在缺陷吗？或者只是设计师认为额外的安全性不值得使协议复杂化？
PS:
如果你认为它会造成太多的开销,你可以强制协议的用户使用互锁仅对第一10K在连接数据的,所以在实践中它不会太大的关系,但MITM会更从来没有那么困难.
更新: 描述的联锁协议的攻击在这里,并不意味着MITM攻击是可能的,它意味着如果通信期间发送一个密码的MITM可以拦截它,用户将只能看到超时错误.
更新2:
点Eugene,加注有效.互锁协议不允许验证.也就是说,你仍然无法确定如果你正在连接example.com,它确实是example.com,而不是malicious.com冒充example.com.如果没有,你肯定不知道DNSSEC.因此,举例来说,如果你是SSH荷兰国际集团的飞弹发射井,以及写launch_missile -time now(不,比方说,使用ls验证服务器确实是在导弹发射井的服务器),这也许是因为你真地写过一个恶意服务器,现在敌人知道你即将发射导弹对付他.互锁协议确实不会阻止这种类型的攻击.
但是,如果我正确理解协议,可能会阻止更危险的攻击和非常实际的攻击.如果使用了互锁协议,即使您不知道任何事情example.com,也不可能SSH对您的服务器,并且有人会窃听到整个SSH会话.我认为这种类型的攻击更有可能.
也许SSH不关心MITM攻击？我想不是,请参阅Putty FAQ:
那些讨厌的主机密钥提示是SSH的全部要点.没有它们,SSH用于保护会话的所有加密技术只不过是让攻击者的工作稍微困难一点; 而不是坐在您和服务器之间使用数据包嗅探器,攻击者实际上必须颠覆路由器并开始修改来回的数据包.但这并不比嗅闻更困难; 如果没有主机密钥检查,它将完全被客户端或服务器检测不到.
他显然是在谈论MITM攻击而不是服务器身份验证.我认为使用互锁协议将清楚地防止Putty FAQ中提到的攻击,我仍然不明白他们为什么不使用它.
如果我使用PHP的fopen()功能从HTTPS网站检索数据,那就是所谓的安全HTTPS连接.即它是否提供针对中间人和窃听攻击的保护？
我试图了解如何绕过 HSTS 保护。我读过 LeonardoNve 的工具（https://github.com/LeonardoNve/sslstrip2和https://github.com/LeonardoNve/dns2proxy）。但我完全不明白。
如果客户端第一次请求服务器，它会随时工作，因为 sslstrip 将简单地剥离 Strict-Transport-Security: 头字段。所以我们回到了原始 sslstrip 的旧案例。
如果不 ... ？发生什么了 ？客户端知道它应该只使用 HTTPS 与服务器交互，所以它会自动尝试使用 HTTPS 连接到服务器，不是吗？在这种情况下，MitM 是无用的...><
查看代码，我有点明白 sslstrip2 将更改客户端所需资源的域名，因此客户端将不必使用 HSTS，因为这些资源不在同一个域中（这是真的吗？）。客户端将发送一个 DNS 请求，dns2proxy 工具将拦截并发回真实域名的 IP 地址。最后，客户端将仅以 HTTPS 方式对它应该完成的资源进行 HTTP 传输。
示例：从服务器响应中，客户端必须下载 mail.google.com。攻击者将其更改为 gmail.google.com，因此它不是相同的（子）域。然后客户端会向这个域发起 DNS 请求，dns2proxy 会回复 mail.google.com 的真实 IP。然后客户端将通过 HTTP 简单地询问这个资源。
我没有得到的是在那之前......攻击者如何在从客户端到服务器的连接应该是HTTPS的情况下进行html-strip......？
少了一块... :s
谢谢
我正在尝试安装squid 3.5.4（在docker上，运行debian 8）并以ssl-bump模式运行它。汇编：
./configure --prefix=/opt/squid --srcdir=. --disable-maintainer-mode \
--disable-dependency-tracking --disable-silent-rules --enable-inline\
--disable-arch-native --enable-async-io=8 \
--enable-storeio=ufs,aufs,diskd,rock \
--enable-removal-policies=lru,heap --enable-delay-pools \
--enable-cache-digests --enable-icap-client \
--enable-follow-x-forwarded-for \
--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB \
--enable-auth-digest=file,LDAP \
--enable-auth-negotiate=kerberos,wrapper \
--enable-auth-ntlm=fake,smb_lm \
--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group \
--enable-url-rewrite-helpers=fake --enable-eui \
--enable-esi --enable-icmp --enable-zph-qos \
--disable-translation --with-filedescriptors=65536 \
--with-large-files --with-default-user=squid \
--enable-linux-netfilter \
CFLAGS="-g -O2 -fPIE -Wall" LDFLAGS="-fPIE -pie -Wl,-z,relro -Wl,-z,now" CPPFLAGS="-D_FORTIFY_SOURCE=2" \
CXXFLAGS="-g -O2 -fPIE " --enable-ssl --with-openssl --enable-ssl-crtd
更改配置（squid.conf）（其余为默认值）：
# Squid normally listens to port 3128 \
http_port 9090
sslcrtd_program /opt/squid/libexec/ssl_crtd -s …我相信我已经知道了答案,但我想知道是否有人对这个问题有了更深入的了解.我已经在Android和iOS应用程序中完成了证书固定,以使它们在中间攻击中更安全.我很好奇,可以在执行Ajax调用的网站上完成同样的事情吗？我想不是因为在运输过程中可以修改Javascript代码,有没有人有这方面的经验？
我正在尝试通过中继所有流量并挑选出某些流量进行修改来man-in-the-middle对HTTPS连接进行攻击。我看着LittleProxy-mitm，以及LittleProxy与这些项目看起来非常有前途的。我按照自述文件编写代码，但是通过此代理运行连接时无法正常工作。我完整的代码如下：
import io.netty.channel.ChannelHandlerContext;
import io.netty.handler.codec.http.*;
import io.netty.util.AttributeKey;
import org.littleshoot.proxy.HttpFilters;
import org.littleshoot.proxy.HttpFiltersAdapter;
import org.littleshoot.proxy.HttpFiltersSourceAdapter;
import org.littleshoot.proxy.impl.DefaultHttpProxyServer;
import org.littleshoot.proxy.mitm.CertificateSniffingMitmManager;
import org.littleshoot.proxy.mitm.RootCertificateException;
import java.net.InetSocketAddress;
import java.util.List;
import java.util.Map;
public class Main
{
private static final AttributeKey<String> CONNECTED_URL = AttributeKey.valueOf("connected_url");
public static void main(String[] arguments) throws RootCertificateException
{
System.out.println("Starting HTTP proxy server...");
DefaultHttpProxyServer.bootstrap()
.withPort(9090)
.withManInTheMiddle(new CertificateSniffingMitmManager())
.withFiltersSource(new HttpFiltersSourceAdapter()
{
@Override
public HttpFilters filterRequest(HttpRequest originalRequest, ChannelHandlerContext ctx)
{
String uri = originalRequest.getUri();
if (originalRequest.getMethod() == …Tl;Dr：我正在创建一个应用程序：两个或多个用户之间的端到端加密聊天，并且需要快速便捷的方式来直观地检查是否存在中间人
Alice 和 Bob 只接受 ID 和公钥，因此无法简单快速地区分他们之间是否存在 ManInTheMiddle，因为 UUID 与某些 SHA 哈希不同，通常看起来非常相似。随后生成的 uuid 可能仅存在单个字符的差异，并且人眼不容易识别这种差异。
javascript encryption avatar man-in-the-middle avatar-generation