精华内容
下载资源
问答
  • HTTPS及HTTPS中间人攻击

    2021-02-01 12:08:46
    HTTPS及HTTPS中间人攻击,全站HTTPS正在称为潮流趋势,国内实现全站https的有淘宝和百度两家。 CIA:机密性,完整性,可用性(可用性是合法用户可以访问自己有权限访问的资源) 解决的是信息传输中数据被篡改、窃取 ...
  • 中间人攻击,Man-in-the-middle attack,缩写:MITM,是指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者...
  • 浅析HTTPS中间人攻击与证书校验

    千次阅读 2018-06-20 08:25:33
    0x00 引言随着安全的普及,https通信应用越发广泛,但是由于对https不熟悉导致...本文第一节主要讲述https的握手过程,第二节主要讲述常见的“https中间人攻击”场景,第三节主要介绍证书校验修复方案,各位看...
    

    0x00 引言

    随着安全的普及,https通信应用越发广泛,但是由于对https不熟悉导致开发人员频繁错误的使用https,例如最常见的是未校验https证书从而导致“中间人攻击”,并且由于修复方案也一直是个坑,导致修复这个问题时踩各种坑,故谨以此文简单的介绍相关问题。

    本文第一节主要讲述https的握手过程,第二节主要讲述常见的“https中间人攻击”场景,第三节主要介绍证书校验修复方案,各位看官可根据自己口味浏览。

    0x01 Https原理

     

    浅析HTTPS中间人攻击与证书校验

     

    首先来看下https的工作原理,上图大致介绍了https的握手流程,后续我们通过抓包看下每个握手包到底干了些什么神奇的事。

    注:本文所有内容以TLS_RSA_WITH_AES_128_CBC_SHA加密组件作为基础进行说明,其他加密组件以及TLS版本会存在一定差异,例如TLS1.3针对移动客户端有了很大的改动,现在的ECDHE等密钥交换算法与RSA作为密钥交换算法也完全不一样,所以有些地方和大家实际操作会存在一定出入。

    1.1 TCP

    TCP的三次握手,这是必须的。

     

    浅析HTTPS中间人攻击与证书校验

     

    1.2 Client Hello

     

    浅析HTTPS中间人攻击与证书校验

     

    TLS的版本号 随机数random_c:这个是用来生成最后加密密钥的因子之一,它包含两部分,时间戳和随机数 session-id:用来标识会话,第一次握手时为空,如果以前建立过,可以直接带过去从而避免完全握手 Cipher Suites加密组件列表:浏览器所支持的加密算法的清单客户端支持的加密签名算法的列表,让服务器进行选择 扩展字段:比如密码交换算法的参数、请求主机的名字,用于单ip多域名的情况指定域名。

     

    浅析HTTPS中间人攻击与证书校验

     

    1.3 Sever Hello

     

    浅析HTTPS中间人攻击与证书校验

     

    随机数rando_s,这个是用来生成最后加密密钥的因子之一,包含两部分,时间戳和随机数 32字节的SID,在我们想要重新连接到该站点的时候可以避免一整套握手过程。 在客户端提供的加密组件中,服务器选择了TLS_RSA_WITH_AES_128_CBC_SHA组件。1.4 Certificate

     

    浅析HTTPS中间人攻击与证书校验

     

    证书是https里非常重要的主体,可用来识别对方是否可信,以及用其公钥做密钥交换。可以看见证书里面包含证书的颁发者,证书的使用者,证书的公钥,颁发者的签名等信息。其中Issuer Name是签发此证书的CA名称,用来指定签发证书的CA的可识别的唯一名称(DN, Distinguished Name),用于证书链的认证,这样通过各级实体证书的验证,逐渐上溯到链的终止点,即可信任的根CA,如果到达终点在自己的信任列表内未发现可信任的CA则认为此证书不可信。

    验证证书链的时候,用上一级的公钥对证书里的签名进行解密,还原对应的摘要值,再使用证书信息计算证书的摘要值,最后通过对比两个摘要值是否相等,如果不相等则认为该证书不可信,如果相等则认为该级证书链正确,以此类推对整个证书链进行校验,引用高性能网络中的证书链校验图。

     

    浅析HTTPS中间人攻击与证书校验

     

     

    浅析HTTPS中间人攻击与证书校验

     

    二级机构的公钥

     

    浅析HTTPS中间人攻击与证书校验

     

    网站证书的签名

    不仅仅进行证书链的校验,此时还会进行另一个协议即Online Certificate Status Protocol, 该协议为证书状态在线查询协议,一个实时查询证书是否吊销的方式,客户端发送证书的信息并请求查询,服务器返回正常、吊销或未知中的任何一个状态,这个查询地址会附在证书中供客户端使用。

    1.5 Server Hello Done

     

    浅析HTTPS中间人攻击与证书校验

     

    这是一个零字节信息,用于告诉客户端整个server hello过程已经结束。

    1.6 ClientKeyExchange

     

    浅析HTTPS中间人攻击与证书校验

     

    客户端在验证证书有效之后发送ClientKeyExchange消息,ClientKeyExchange消息中,会设置48字节的premaster secret,通过密钥交换算法加密发送premaster secret的值,例如通过 RSA公钥加密premaster secret的得到Encrypted PreMaster传给服务端。PreMaster前两个字节是TLS的版本号,该版本号字段是用来防止版本回退攻击的。

    从握手包到目前为止,已经出现了三个随机数(客户端的random_c,服务端的random_s,premaster secret),使用这三个随机数以及一定的算法即可获得对称加密AES的加密主密钥Master-key,主密钥的生成非常的精妙,通过阅读RFC2246文档以及openssl的函数int master_secret(unsigned char *dest,int len,unsigned char *pre_master_secret,int pms_len,unsigned char *label,unsigned char *seed,int seed_len)可得到主密钥的生成过程如下:

    1 2 PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);

    函数中的参数定义如下:

    secret即为pre secret ,label是一个字符串,seed为random_c+random_s,S1为前半部分的pre secret,S2为后半部分的pre secret。分别使用P_MD5()和P_SHA-1进行hash计算得到两个hash,再使用这两个hash进行异或得到最终的主密钥master key,这两个hash由下面的运算得来:

    1 2 3 P_hash(1/2secret, label,seed) = HMAC_hash(1/2secret, A(1) + seed) + HMAC_hash(1/2secret, A(2) + seed) + HMAC_hash(1/2secret, A(3) + seed) + ...

    P_hash()是P_MD5()和P_SHA-1()的统称。

    A()的赋值相对比较复杂,变形后如下:

    1 2 A(0)=HMAC(md5,1/2secret,strlen(1/2secret), actual_seed(0), strlen(label)+strlen(seed),temp_md5,NULL); //temp_md5数组用于接收最后生成的hash,attual_seed为label和seed结合 A(0) = HMAC(sha,1/2secret,strlen(1/2secret) , actual_seed(0), strlen(label)+strlen(seed),temp_sha,NULL);// temp_sha数组用于接收最后生成的hash,attual_seed为label和seed结合

    简化表达如下:

    1 A(i)=HMAC_hash(1/2secret,A(i-1)+seed)

    由于只进行一次SHA-1或者MD5产生的hash字节数是不够的,所以使用迭代的方式产生足够多的hash,多出来的hash则直接抛弃。例如,使用P_SHA-1()产生64字节的数据,就需要迭代4次(通过A(4)),产生80字节的输出数据,最后迭代产生的16字节将会被抛弃,只留下64字节的数据,如果使用P_MD5()则需要迭代5次。

    1.7 Change Cipher Spec

     

    浅析HTTPS中间人攻击与证书校验

     

    发送一个不加密的信息,浏览器使用该信息通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信。

    1.8 Encrypted Handshake Message

     

    浅析HTTPS中间人攻击与证书校验

     

    验证加密算法的有效性,结合之前所有通信参数的 hash 值与其它相关信息生成一段数据,采用协商密钥 session secret 与算法进行加密,然后发送给服务器用于数据与握手验证,通过验证说明加密算法有效。

    1.9 Change_cipher_spec

     

    浅析HTTPS中间人攻击与证书校验

     

    Encrypted Handshake Message通过验证之后,服务器同样发送 change_cipher_spec 以通知客户端后续的通信都采用协商的密钥与算法进行加密通信。这里还有一个New Session Ticket并不是必须的,这是服务器做的优化,后续我们再讲解该协议的作用。

    1.10 Encrypted Handshake Message

     

    浅析HTTPS中间人攻击与证书校验

     

    同样的,服务端也会发送一个Encrypted Handshake Message供客户端验证加密算法有效性。

    1.11 Application Data

     

    浅析HTTPS中间人攻击与证书校验

     

    经过一大串的的计算之后,终于一切就绪,后续传输的数据可通过主密钥master key进行加密传输,加密数据查看图中的Encrypted Apploication Data字段数据,至此https的一次完整握手以及数据加密传输终于完成。

    https里还有很多可优化并且很多精妙的设计,例如为了防止经常进行完整的https握手影响性能,于是通过sessionid来避免同一个客户端重复完成握手,但是又由于sessionid消耗的内存性能比较大,于是又出现了new session ticket,如果客户端表明它支持Session Ticket并且服务端也支持,那么在TLS握手的最后一步服务器将包含一个“New Session Ticket”信息,其中包含了一个加密通信所需要的信息,这些数据采用一个只有服务器知道的密钥进行加密。这个Session Ticket由客户端进行存储,并可以在随后的一次会话中添加到 ClientHello消息的SessionTicket扩展中。虽然所有的会话信息都只存储在客户端上,但是由于密钥只有服务器知道,所以Session Ticket仍然是安全的,因此这不仅避免了性能消耗还保证了会话的安全性。

    最后我们可以使用openssl命令来直观的看下https握手的流程:

     

    浅析HTTPS中间人攻击与证书校验

     

    0x02 中间人攻击

    https握手过程的证书校验环节就是为了识别证书的有效性唯一性等等,所以严格意义上来说https下不存在中间人攻击,存在中间人攻击的前提条件是没有严格的对证书进行校验,或者人为的信任伪造证书,下面一起看下几种常见的https“中间人攻击”场景。

    2.1 证书未校验

    由于客户端没有做任何的证书校验,所以此时随意一张证书都可以进行中间人攻击,可以使用burp里的这个模块进行中间人攻击。

     

    浅析HTTPS中间人攻击与证书校验

     

    通过浏览器查看实际的https证书,是一个自签名的伪造证书。

     

    浅析HTTPS中间人攻击与证书校验

     

    2.2 部分校验

    做了部分校验,例如在证书校验过程中只做了证书域名是否匹配的校验,可以使用burp的如下模块生成任意域名的伪造证书进行中间人攻击。

     

    浅析HTTPS中间人攻击与证书校验

     

    实际生成的证书效果,如果只做了域名、证书是否过期等校验可轻松进行中间人攻击(由于chrome是做了证书校验的所以会提示证书不可信任)。

     

    浅析HTTPS中间人攻击与证书校验

     

    2.3 证书链校验

    如果客户端对证书链做了校验,那么攻击难度就会上升一个层次,此时需要人为的信任伪造的证书或者安装伪造的CA公钥证书从而间接信任伪造的证书,可以使用burp的如下模块进行中间人攻击。

     

    浅析HTTPS中间人攻击与证书校验

     

     

    浅析HTTPS中间人攻击与证书校验

     

    可以看见浏览器是会报警告的,因为burp的根证书PortSwigger CA并不在浏览器可信任列表内,所以由它作为根证书签发的证书都是不能通过浏览器的证书校验的,如果将PortSwigger CA导入系统设置为可信任证书,那么浏览器将不会有任何警告。

    2.4 手机客户端Https数据包抓取

    上述第一、二种情况不多加赘述,第三种情况就是我们经常使用的抓手机应用https数据包的方法,即导入代理工具的公钥证书到手机里,再进行https数据包的抓取。导入手机的公钥证书在android平台上称之为受信任的凭据,在ios平台上称之为描述文件,可以通过openssl的命令直接查看我们导入到手机客户端里的这个PortSwiggerCA.crt

     

    浅析HTTPS中间人攻击与证书校验

     

    可以看见是Issuer和Subject一样的自签名CA公钥证书,另外我们也可以通过证书类型就可以知道此为公钥证书,crt、der格式的证书不支持存储私钥或证书路径(有兴趣的同学可查找证书相关信息)。导入CA公钥证书之后,参考上文的证书校验过程不难发现通过此方式能通过证书链校验,从而形成中间人攻击,客户端使用代理工具的公钥证书加密随机数,代理工具使用私钥解密并计算得到对称加密密钥,再对数据包进行解密即可抓取明文数据包。

    2.5 中间人攻击原理

    一直在说中间人攻击,那么中间人攻击到底是怎么进行的呢,下面我们通过一个流行的MITM开源库mitmproxy来分析中间人攻击的原理。中间人攻击的关键在于https握手过程的ClientKeyExchange,由于pre key交换的时候是使用服务器证书里的公钥进行加密,如果用的伪造证书的公钥,那么中间人就可以解开该密文得到pre_master_secret计算出用于对称加密算法的master_key,从而获取到客户端发送的数据;然后中间人代理工具再使用其和服务端的master_key加密传输给服务端;同样的服务器返回给客户端的数据也是经过中间人解密再加密,于是完整的https中间人攻击过程就形成了,一图胜千言,来吧。

     

    浅析HTTPS中间人攻击与证书校验

     

    通过读Mitmproxy的源码发现mitmproxy生成伪造证书的函数如下:

     

    浅析HTTPS中间人攻击与证书校验

     

    通过上述函数一张完美伪造的证书就出现了,使用浏览器通过mitmproxy做代理看下实际伪造出来的证书。

     

    浅析HTTPS中间人攻击与证书校验

     

    可以看到实际的证书是由mimtproxy颁发的,其中的公钥就是mimtproxy自己的公钥,后续的加密数据就可以使用mimtproxy的私钥进行解密了。如果导入了mitmproxy的公钥证书到客户端,那么该伪造的证书就可以完美的通过客户端的证书校验了。这就是平时为什么导入代理的CA证书到手机客户端能抓取https的原因。

    0x03 App证书校验

    通过上文第一和第二部分的说明,相信大家已经对https有个大概的了解了,那么问题来了,怎样才能防止这些“中间人攻击”呢?

    app证书校验已经是一个老生常谈的问题了,但是市场上还是有很多的app未做好证书校验,有些只做了部分校验,例如检查证书域名是否匹配证书是否过期,更多数的是根本就不做校验,于是就造成了中间人攻击。做证书校验需要做完全,只做一部分都会导致中间人攻击,对于安全要求并不是特别高的app可使用如下校验方式:

    查看证书是否过期 服务器证书上的域名是否和服务器的实际域名相匹配 校验证书链

    可参考http://drops.wooyun.org/tips/3296,此类校验方式虽然在导入CA公钥证书到客户端之后会造成中间人攻击,但是攻击门槛已相对较高,所以对于安全要求不是特别高的app可采用此方法进行防御。对于安全有较高要求一些app(例如金融)上述方法或许还未达到要求,那么此时可以使用如下更安全的校验方式,将服务端证书打包放到app里,再建立https链接时使用本地证书和网络下发证书进行一致性校验,可参考安卓官方提供的https连接demo:https://developer.android.com/training/articles/security-ssl.html

    #!java
    import java.io.BufferedInputStream;
    import java.io.ByteArrayOutputStream;
    import java.io.FileInputStream;
    import java.io.InputStream;
    import java.net.URL;
    import java.security.KeyStore;
    import java.security.cert.Certificate;
    import java.security.cert.CertificateFactory;
    import java.security.cert.X509Certificate;
    
    import javax.net.ssl.HttpsURLConnection;
    import javax.net.ssl.SSLContext;
    import javax.net.ssl.TrustManagerFactory;
    
    import android.content.Context;
    import android.util.Log;
    
    public class TestHttpsConnect {
        public static void test(Context mcontext, String name, String weburl) throws Exception {
    
            CertificateFactory cf = CertificateFactory.getInstance("X.509");
            InputStream caInput = new BufferedInputStream(new FileInputStream("baidu.cer"));
            Certificate ca;
            try {
                ca = cf.generateCertificate(caInput);
                System.out.println("ca=" + ((X509Certificate) ca).getSubjectDN());
            } finally {
                caInput.close();
            }
    
            String keyStoreType = KeyStore.getDefaultType();
            KeyStore keyStore = KeyStore.getInstance(keyStoreType);
            keyStore.load(null, null);
            keyStore.setCertificateEntry("ca", ca);
    
            String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
            TrustManagerFactory tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
            tmf.init(keyStore);
    
            SSLContext context = SSLContext.getInstance("TLS");
            context.init(null, tmf.getTrustManagers(), null);
    
            URL url = new URL(weburl);
            HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection();
            urlConnection.setSSLSocketFactory(context.getSocketFactory());
            InputStream in = urlConnection.getInputStream();
            ByteArrayOutputStream arrayOutputStream = new ByteArrayOutputStream();
    
            byte[] buffer = new byte[1024];
            int len = -1;
            while ((len = in.read(buffer)) >= 0) {
                arrayOutputStream.write(buffer, 0, len);
            }
    
            Log.e("", arrayOutputStream.toString());
    
        }
    
    }
    

    此类校验即便导入CA公钥证书也无法进行中间人攻击,但是相应的维护成本会相对升高,例如服务器证书过期,证书更换时如果app不升级就无法使用,那么可以改一下:

    生成一对RSA的公私钥,公钥可硬编码在app,私钥放服务器。 https握手前可通过服务器下发证书信息,例如公钥、办法机构、签名等,该下发的信息使用服务器里的私钥进行签名; 通过app里预置的公钥验签得到证书信息并存在内容中供后续使用; 发起https连接获取服务器的证书,通过对比两个证书信息是否一致进行证书校验。

    这样即可避免强升的问题,但是问题又来了,这样效率是不是低太多了?答案是肯定的,所以对于安全要求一般的应用使用第一种方法即可,对于一些安全要求较高的例如金融企业可选择第二种方法。

    说了挺多,但是该来的问题还是会来啊!现在的app一般采用混合开发,会使用很多webveiw直接加载html5页面,上面的方法只解决了java层证书校验的问题,并没有涉及到webview里面的证书校验,对于这种情况怎么办呢?既然问题来了那么就一起说说解决方案,对于webview加载html5进行证书校验的方法如下:

    webview创建实例加载网页时通过onPageStart方法返回url地址; 将返回的地址转发到java层使用上述的证书校验代码进行进行校验; 如果证书校验出错则使用stoploading()方法停止网页加载,证书校验通过则正常加载。

    提供参考代码如下:
     

    #!java
    package com.example.testhttps;
    
    import java.io.InputStream;
    import java.net.URL;
    import java.security.KeyStore;
    import java.security.cert.Certificate;
    import java.security.cert.CertificateFactory;
    import java.security.cert.X509Certificate;
    
    import javax.net.ssl.HttpsURLConnection;
    import javax.net.ssl.SSLContext;
    import javax.net.ssl.TrustManagerFactory;
    
    import android.app.Activity;
    import android.content.Intent;
    import android.graphics.Bitmap;
    import android.net.http.SslError;
    import android.os.AsyncTask;
    import android.os.Bundle;
    import android.util.Log;
    import android.webkit.SslErrorHandler;
    import android.webkit.WebView;
    import android.webkit.WebViewClient;
    import android.widget.Toast;
    
    public class TestWebViewActivity extends Activity {
    
        static final String TAB = "MainActivity";
        WebView mWebView;
    
        SSLContext mSslContext;
        KeyStore keyStore;
        TrustManagerFactory tmf;
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            // TODO Auto-generated method stub
            super.onCreate(savedInstanceState);
    
            setContentView(R.layout.test_webview_acitity);
    
            iniData();
    
            mWebView = (WebView) findViewById(R.id.webView1);
            mWebView.setWebViewClient(new MyWebViewClient());
            mWebView.getSettings().setJavaScriptEnabled(true);
    
            Intent i = getIntent();
            String url = i.getStringExtra("url");
            mWebView.loadUrl(url);
        }
    
        /**
         * 初始化证书
         */
        void iniData() {
            try {
    
                CertificateFactory cf = CertificateFactory.getInstance("X.509");
                InputStream caInput = getAssets().open("baidu.cer");
                Certificate ca;
                try {
                    ca = cf.generateCertificate(caInput);
                    System.out.println("ca=" + ((X509Certificate) ca).getSubjectDN());
                } finally {
                    caInput.close();
                }
    
                String keyStoreType = KeyStore.getDefaultType();
                keyStore = KeyStore.getInstance(keyStoreType);
                keyStore.load(null, null);
                keyStore.setCertificateEntry("ca", ca);
    
                String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
                tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
                tmf.init(keyStore);
    
                mSslContext = SSLContext.getInstance("TLS");
                mSslContext.init(null, tmf.getTrustManagers(), null);
            } catch (Exception e) {
                Log.e("", "iniData error");
                e.printStackTrace();
            }
        }
    
        class MyWebViewClient extends WebViewClient {
    
            @Override
            public void onPageStarted(WebView view, String url, Bitmap favicon) {
                // TODO Auto-generated method stub
                super.onPageStarted(view, url, favicon);
    
                // 如果不是https,不用校验
                if (!url.startsWith("https://")) {
                    return;
                }
    
                final WebView tempView = view;
                final String tempurl = url;
    
                /**
                 * 测试url校验,如果不通过,就不加载
                 */
                new AsyncTask() {
    
                    @Override
                    protected Boolean doInBackground(String... params) {
                        // TODO Auto-generated method stub
                        try {
                            // 检验证书是否正确
                            URL url = new URL(tempurl);
                            HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection();
                            urlConnection.setSSLSocketFactory(mSslContext.getSocketFactory());
                            InputStream in = urlConnection.getInputStream();
                            in.close();
                            // TestHttpsConnect.test(TestWebViewActivity.this,
                            // "baidu.cer", tempurl);
                        } catch (Exception e) {
                            // TODO Auto-generated catch block
                            e.printStackTrace();
                            return false;
                        }
                        return true;
                    }
    
                    protected void onPostExecute(Boolean result) {
                        if (!result) {
                            Toast.makeText(TestWebViewActivity.this, "证书校验错误", Toast.LENGTH_SHORT).show();
                            tempView.stopLoading();
                        }
                    };
    
                }.execute(url);
            }
    
            @Override
            public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
                // TODO Auto-generated method stub
                super.onReceivedSslError(view, handler, error);
                // Log.e(TAB, "onReceivedSslError");
            }
        }
    
    }
    
    展开全文
  • Https中间人攻击实例演示

    千次阅读 2019-07-17 16:33:36
    实现抓包后对请求url断点调试,篡改报文 拦截APP请求,修改请求参数重新触发请求 应用场景: 拦截请求报文,篡改请求报文,篡改响应报文等。 ...2、再次刷新APP页面,触发请求,此时...实现中间人拦截,报文篡改

    实现抓包后对请求url断点调试,篡改报文

    拦截APP请求,修改请求参数重新触发请求
    应用场景:
    拦截请求报文,篡改请求报文,篡改响应报文等。
    先看效果:
    篡改前页面:
    在这里插入图片描述
    篡改后页面:
    在这里插入图片描述
    配置步骤:
    1、选中要拦截监控的url,选择如下图,开启抓包监控:
    在这里插入图片描述
    2、再次刷新APP页面,触发请求,此时会发现请求进入断点拦截——此时可以选择Edit Request来篡改请求报文
    在这里插入图片描述
    3、接着点击Excute执行请求发送,进入响应报文拦截断点,可以在此修改返回报文,然后再点击excute将修改后的返回报文返回给前端展示。实现中间人拦截,报文篡改
    在这里插入图片描述

    展开全文
  • 【安全系列】https中间人攻击

    千次阅读 2020-08-28 20:31:21
    https相对http更加安全,然而https并不是那么完美,中间人还是可以通过很多手段来绕过https,比如https证书伪造,或者强制转换http协议,或者加密降级等等。


    前言

    刚了解了https是如何加密传输,但是https却又不是那么得完美,中间人还是通过各种手段来获取目标信息。废话不多说,开始演示。


    一、证书伪造攻击

    1.实现思路

    在这里插入图片描述
    中间人在服务器和浏览器中间。面向服务器时,他伪装成一个浏览器客户端,面向浏览器时,他伪装成一个服务器。主要实现步骤如下:

    1. 中间人想办法对浏览器到服务器的数据进行拦截,通过arp欺骗或者dns欺骗等等,方式有很多,需要按照自己的场景进行处理。
    2. 服务器收到https请求时,会下发证书,这个证书是可以得CA认证的,中间人同样可以从证书中获取服务器的公钥。
    3. 中间人创建一个根证书,通过这个根证书对服务器下发的证书继续伪造,伪造成功后下发给客户端。
    4. 浏览器收到一个假的证书,不会通过证书检测,会报一个网上不是安全的,是否继续等等的异常信息,异常信息如下。这个时候如果用户就是想要访问的话,之后所有和该服务器交互的信息都会被中间人获取。
      在这里插入图片描述
      基本每个https的网站都会有这种异常信息,证书伪造会使得用户有感知,如果是知道这种攻击方式的人,就会对攻击的效果有影响。这种异常信息也是可以去除的,就是使得用户浏览器安装中间人创建的根证书,使得中间人颁发的证书得到信任即可,在开发的过程中,经常使用fiddler来抓取https的包,原理就是使用了证书伪造。

    2.实施攻击

    2.1.生成私钥
    openssl genrsa -out ca.key 2048
    2048表示私钥的长度
    2.2.通过私钥生成证书

    kali@kali:~$ openssl req -new -x509 -days 1096 -key ca.key -out ca.crt
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    #国家名称
    Country Name (2 letter code) [AU]:CN   
    #省份
    State or Province Name (full name) [Some-State]:zhejiang
    #城市
    Locality Name (eg, city) []:Hangzhou
    #公司名称
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:Alibaba
    Organizational Unit Name (eg, section) []:ali
    Common Name (e.g. server FQDN or YOUR name) []:alibaba
    

    在根证书生成的时候,需要填写一些信息达到仿真的效果,这个按照自己的想法,尽可能高仿就可以了,没什么大的用处,就是用来看着像真的证书颁发者就可以了。
    2.3开启路由转发
    sysctl -w net.ipv4.ip_forward=1
    用户到达kali的流量需要转发出去,所以开起路由转发。
    2.4端口转发
    80端口转发到8080
    sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
    443 端口转发到8443
    sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
    2.5实施监听
    sudo sslsplit -D -l connect.log -j https/ -S https/logdir/ -k ca.key -c ca.crt ssl 0.0.0.0 8443 tcp 0.0.0.0 8080
    在执行之前需要在当前目录下创建https目录和https/logdir目录

    1. -D debug模式,显示较多的日志信息
    2. -l 连接请求的信息记录到connec.log中
    3. -j root根目录(简单理解就好)
    4. -S 日志目录
    5. -k 指定私钥
    6. -c 指定证书

    二、协议转换攻击

    1.实现思路

    在这里插入图片描述

    在平时访问百度的时候,即使使用http访问百度的时候,百度也会重定向到https,通过这一个思路,翻转一下,用户如果使用https访问服务器的时候,返回重定向信息,使得浏览器使用http协议到中间人,中间人收到浏览器请求的时候,代理浏览器和服务器进行交互。
    这种思路没有了证书的验证,也没有了浏览器异常的抛出,相对于用户是无感知的,更容易达到攻击的效果。

    2.实施攻击

    通过sslstrip进行攻击,下载地址:https://github.com/moxie0/sslstrip

    下载之后通过github中教程进行安装,通过python sslstrip.py -l 8080 启动。
    之后可以通过arp欺骗等等,进行信息拦截。

    每天学一点,进去早一点,大家切勿做坏事。

    系列文章目录

    【安全系列】wireshark解析https

    展开全文
  • HTTPS 中间人攻击及其防范

    千次阅读 2018-10-09 12:01:58
    转自:https://rolandreed.cn/post/Man-In-Middle-Attack
    展开全文
  • https中间人攻击

    2009-08-15 14:57:13
    ssl中间人攻击,用于劫持ssl会话,并且获得明文。
  • 基于Android的http&https中间人攻击

    千次阅读 2017-10-13 10:45:35
    本文所说的中间人攻击是在同一台Android手机上,监听其他App的网络流量,支持http&https. 原理:通过创建VPN拿到其他APP的所有网络流量。https部分则是通过导入自己的CA,去过https证书验证。 主要技术难点: 1.通过...
  • 文章目录介绍浏览器查看公钥证书OpensslSSLScanNmapQUALYS SSL LABS网站SSL/TLS中间人攻击原理SSLsplitopenssl生成证书私钥,再生成私钥签名证书。步骤让中间人实现路由功能ARP欺骗启动SSLSplit侦听端口攻击成功后...
  • HTTPS怎么避免中间人攻击

    千次阅读 2020-09-30 12:30:05
    在谈论 HTTPS 协议之前,先来回顾一下 HTTP 协议的概念。 1.1 HTTP 协议介绍 HTTP 协议是一种基于文本的传输协议,它位于 OSI 网络模型中的应用层。 HTTP 协议是通过客户端和服务器的请求应答来进行通讯,目前...
  • HTTPS中间人攻击对自己签发的证书比较有效,比如xfocus这样的。因为本来就会出现证书警告,而向yahoo,google等网站,是权威机构发布的证书,伪造了之后会出现安全警告,不过我想白痴的用户还是很多吧。另外,这种...
  • https原理及中间人劫持防御方法论文,知网上下载的论文,在这里分享出来。
  • 随着 HTTPS 建站的成本下降,现在大部分的网站都已经开始用上 HTTPS 协议。大家都知道 HTTPS 比 HTTP 安全,也听说过与 HTTPS 协议相关的概念有 SSL 、非对称加密、 CA证书等,但对于以下灵魂三拷问可能就答不上了:...
  • HTTPS 防范中间人攻击原理

    千次阅读 2020-10-16 18:45:25
    HTTPS因为增加了CA证书,可以在会话前通过证书验证证明通信的彼此就是所声称的人,因此可以防范中间人攻击。这种防范中间人攻击的前提是在HTTPs协议的双向认证上。如果仅仅实现了HTTPs的单向认证,如不验证客户端,...
  • 1.什么是中间人攻击? 在手机或者电脑和服务器建立连接的时候,攻击者通过工具或者技术手段将自己位于两端之间,获取数据,进行监听活动的就是中间人攻击。 2.有哪几种攻击: 1.嗅探,监听获取连接数据包。 2....
  • 关于HTTPS,我经常会提到的就是中间人攻击,那究竟什么是中间人攻击呢?中间人攻击,即所谓的Main-in-the-middle attack(MITM),顾名思义,就是攻击者插入到原本直接通信的双方,让双方以为还在直接跟对方通讯,但...
  • 讲两块内容:charles实现https抓包;使用charles实现请求报文和响应报文数据篡改。 进入正题: 一、charles配置证书实现https抓包 配置步骤: 1、保证手机跟mac连接的通一个网,即连接同一个wifi或4G热点即可。 2、...
  • 基于HTTPS中间人攻击-BaseProxy

    千次阅读 2018-07-11 18:16:00
    在知识星球中,有很多朋友问我这个项目的原理及实现代码,本篇文章就讲解一下和这个项目相关的HTTPS中间人攻击HTTPS隧道代理 HTTPS隧道代理简单来说是基于TCP协议数据透明转发,在RFC中,为这类代理给出了规范...
  • HTTPS连接过程以及中间人攻击劫持

    万次阅读 多人点赞 2018-05-07 09:09:47
    一 、HTTPS连接过程及中间人攻击原理https协议就是http+ssl协议,如下图所示为其连接过程: 1.https请求 客户端向服务端发送https请求; 2.生成公钥和私钥 服务端收到请求之后,生成公钥和私钥。公钥相当于是锁...
  • 实现一个ssl的客户端和服务端,作为中间人攻击,截取ssl通讯中的密文数据,并进行解密,使用时用把所有的报文都转向给程序所在的机器。
  • 一、场景环境 攻击机: kali 目标机: WinServer 2003 二、原理 攻击前提: 客户端已经信任伪造证书颁发机构;...(攻击者代理服务器)攻击者 通过ARP欺骗客户端通过攻击者做网关,数据包通过攻击者发出。此...
  • 编写此文,帮助广大开发者提高安全意识,真正利用https防止中间人攻击。客户端与服务端进行接口交互如果使用https有单向认证和双向认证两种。一、SSL协议加密方式 SSL协议即用到了对称加密也用到了非对称加密(公钥...
  • 1.为什么使用Https是安全的? 2.Https的底层原理如何实现? 3.使用Https是绝对安全的吗? Https实现原理 Https协议在内容传输上使用的加密是“对称加密”,而“非对称加密”只作用于证书验证阶段。 Https的整体实现...
  • 【实战】用 Python 实现中间人攻击

    千次阅读 多人点赞 2021-02-13 08:00:00
    文 |豆豆来源:Python 技术「ID: pythonall」中间人攻击,顾名思义,就是客户端和服务端的通信被第三者拦截了,这样通信双方的通信内容就会被窃听。你可能会认为,没关系啊,窃...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 33,803
精华内容 13,521
关键字:

https中间人攻击