0.背景 聆听了n1nty大佬(90后黑客代表)的谆谆指导,学习了n1nty大佬的基本操作,决定总结一下,做一个简要的读书笔记,也把之前自己记录的关于Windows的安全的一些博客能够串联起来.所以首先鸣谢:90后黑客代表n1nty大佬. 1.Kerberos的基本认证 1.1.NTLM的挑战认证 不啰嗦,直接说要点,server接到client的请求认证后,会回复16字节随机数据,也就是挑战.client使用自己生成的账号的NTLM的hash值对挑战数据进行某种加密运算,发送到server,s

原理 我们先回顾一下SSL/TLS的整个握手过程: Clienthello:发送客户端的功能和首选项给服务器,在连接建立后,当希望重协商.或者响应服务器的重协商请求时会发送. version:客户端支持的最佳协议版本 Random:共32字节,28字节随机数,4字节额外信息,受客户端时钟影响(为了避免浏览器指纹采集,现在一般会对4字节时钟做扭曲) Session ID:32字节随机数,用于和服务器重建会话,为空表示新建会话 cipher suit:客户端支持的所有密码套件,按优先级排列 Comp

如何利用Wireshark解密SSL和TLS流量https://support.citrix.com/article/CTX135121 1.有server端的private key,直接在wireshark上使用Edit > Preferences->Protocols->RSA keys list 这个protocol必须是小写http,用了大写的会报错...key file必须-----BEGIN RSA PRIVATE KEY-----,如果是-----BEGIN ENCRYPT

wireshark 解密IPSec加密后的报文 序言 wireshark作为一款非常优秀的抓包工具,支持了各种各样的网络协议,成为了网络开发中必不可少的工具之一.一般而言,对于普通的网络数据包,wireshark能够提供很好的解析功能,但是对于加密的网络报文,由于缺乏密钥信息导致无法解析.幸运的时,新版的wireshark工具再一直密钥信息的情况下,提供了解析加密报文的功能.下面我们就该功能的使用提供一个简单的操作示例. 1. 正常抓取的报文 正常抓取的报文,wireshark无法解密.如果需要

此方式支持firefox,chrome 建立path变量 SSLKEYLOGFILE=c:\ssl.key 重启firefox chrome,访问https网站会自动生成ssl session key linux,mac 使用export建立变量 export SSLKEYLOGFILE=/tmp/ssl.key 打开wireshark,Edit--->Preferences--->Protocols--->ssl 在(pre) -master-secret log filename:这

原文地址:http://kelvinh.github.io/blog/2014/01/12/decrypt-ssl-using-fiddler-and-wireshark/ Fiddler是一个著名的调试代理工具,它不仅能解析HTTP,而且还能解析加密的HTTPS流量.Wireshark则是一个非常强大的网络包监控以及协议分析工具. 在本文中,只考虑使用SSL来加密HTTP,所以并不严格区分SSL和HTTPS,虽然从广义上来讲,将二者混为一谈是非常不合理的 . 看到这里,大多数人都会很困惑:Fi

如果是chrome浏览器的数据流 直接配置”SSLKEYLOGFILE“就可以解密了. 实现过程: 1.配置系统环境变量 变量名:SSLKEYLOGFILE 变量值:随意指定一个存储路径,以便chrome输出keylog 2.配置Wireshark 填入你在系统变量中指定的keylog存储路径,以便wireshark访问keylog中的key 从而解密https(ssl) 原理解析: 当你配置了”SSLKEYLOGFILE“这个环境变量,这意味着你告诉chrome 你想知道chrome每次htt

在我之前的一篇文章中已经介绍了一种解密HTTPS流量的一种方法,大致方法就是客户端手动信任中间人,然后中间人重新封包SSL流量. 文章地址: http://professor.blog.51cto.com/996189/1746183 方法概览 今天给大家介绍另外一种解密HTTPS流量的方法. Wireshark 的抓包原理是直接读取并分析网卡数据,要想让它解密 HTTPS 流量,有两个办法: 如果你拥有 HTTPS 网站的加密私钥,可以用来解密这个网站的加密流量: 某些浏览器支持将 TLS 会

为什么Wireshark无法解密HTTPS数据 导读 由于需要定位一个问题,在服务器上tcpdump抓取https数据包,然后下载到本地打开wireshark分析.然后我们下载域名私钥配置到wireshark,发现数据包居然无法解密.是wireshark配置密钥的方法不对?但谷歌了好多文章都是说这样配置的.由于对HTTPS认识不够深,一时不知道如何入手解决.没办法,只能先了解tls这个协议了,于是查看了TLS1.2的RFC文档,终于勉强解答了这个疑惑. TLS握手整个过程 在解决这个问题之前,先

基于wireshark抓包的分析 首先使用wireshark并且打开浏览器,打开百度(百度使用的是HTTPS加密),随意输入关键词浏览. 我这里将抓到的包进行过滤.过滤规则如下 ip.addr == 115.239.210.27 && ssl 1 下面用图来描述一下上面抓包所看到的流程. 1. Client Hello 打开抓包的详细,如下. 不难看出,这一握手过程,客户端以明文形式传输了如下信息: 版本信息(TLS 1.2) 随机数 Session ID(用于加快握手过程,可参考TLS会

tcpdump抓包命令: root#tcpdump -I eth0 -s 80 -w /tmp/tcpdump.cap 注:其中80表示,只抓每个包的前80个字节. 抓包时就筛选自己需要的包: Wireshark抓包前Capture→Options,在Capture Filter中输入“host 10.10.100.10”,然后再抓. tcpdump抓包对应的命令: root#tcpdump -I eth0 host 10.10.100.10 -w /tmp/tcpdump.cap 小技巧: p

前言 分析网络流量总是绕不开HTTPS,因其广泛使用甚至是强制使用逐渐被大众熟知,在保证其安全的同时也提高了对流量进行研究的难度.目前解析HTTPS协议的文章很多,有很多不错的文章可以带着入门,老实说,HTTPS协议还是挺复杂的,尤其是握手交换密钥的过程:虽然大部分的文章只是对协议握手的过程做了详细的解析,却很少涉及HTTPS网络数据包解密的部分,因此,本文即是从数据包层面,在知道私钥的情况下,来一步一步看如何对HTTPS的内容进行解密. 正文 要对HTTPS网络数据包进行解密,其实是有一些工具

wireshark解密IPSEC加密过的流量 题目是安恒二月月赛题目:简单的流量分析 1.首先会发现很多esp类型的流量 我们不知道密钥就没有办法解密,猜测密钥肯定是在流量包里面的. 加密流量在786到1583之间 2. abc.html md5 0x99a98e067af6b09e64f3740767096c96 DES 0xb19b21e80c685bcb052988c11b987802d2f2808b2c2d8a0d (129->143) DES 0x684a0857b767672d52e

WireShark   Wireshark解密TLS数据流,从网上已有资料来看,主要是两种方式:一是服务端私钥直接解密,二是使用SSLKEYLOGFILE获取握手过程中的会话密钥信息进行解密.   这里只尝试第二种方式解密TLS数据.可用的应用包括:chrome.Firefox.curl.   首先设置SSLKEYLOGFILE用户环境变量,值为自定义的文件路径.示例:   或是启动浏览器进程时追加参数--ssl-key-log-file=<PATH>.   测试开始,开启wireshark,

亚马逊AWS IoT使用MQTTS(在TLS上的MQTT)来提供物联网设备与云平台直接的通信功能.出于安全考虑,建议给每个设备配备了证书来认证,同时,设备也要安装亚马逊的根证书:这样,在使用8883端口建立TLS连接时,客户端SDK既对AWS进行验证,同时AWS IoT也对设备的证书进行验证.由此,便对中间人攻击带来了较高的要求,下面记录一下这几天的爬坑经理. 0.方案 整体方案类似于这个:https://wiki.dequis.org/notes/facebook/ 用Host-Only模式的

0.前言 前一阵子想写一个HTTPS的嗅探工具,之前只是大致了解SSL/TLS协议的加密流程,真正上起手来一步一步分析发现还是有点复杂的,于是我参考了wireshark的源码以及各种RFC,弄清楚了SSL/TLS从证书传递到密钥交换,再到数据传输的具体过程,算是小有收获,在这里分享给大家. 因为我想结合一个具体的简单的例子来做分析,所以本篇文章先介绍如何简单搭建一个环境来帮助我们下一步的分析,因此不打算亲自动手实践的朋友可以跳过直接进入下一篇,当然本篇文章还是有些小知识点的. 1.前期准备 1.

前言 为了降低加载时间,相信大多数人都做过如下尝试 Keep-alive: TCP持久连接,增加了TCP连接的复用性,但只有当上一个请求/响应完全完成后,client才能发送下一个请求 Pipelining: 可同时发送多个请求,但是服务器必须严格按照请求的先后顺序返回响应,若第一个请求的响应迟迟不能返回,那后面的响应都会被阻塞,也就是所谓的队头阻塞 请求合并:雪碧图,css/js内联.css/js合并等,然而请求合并又会带来缓存失效.解析变慢.阻塞渲染.木桶效应等诸多问题 域名散列:绕过了同域

Wireshark和Fiddler的优缺点: ①Wireshark是一种在网络层上工作的抓包工具,不仅自带大量的协议分析器,而且可以通过编写Wireshark插件来识别自定义的协议.虽然Wireshark功能强大,但是却并不能解决所有的抓包问题,其原因在于:Wireshark工作在网络层:如果计算机配置了IPSec传输层加密,则在网络层的流量都已经被加密,什么也看不到.当今大量网络接口使用HTTPS加密,Wireshark不能抓取到HTTPS流量的明文内容. ②Fiddler工作在应用层上,作为

前言   为了降低加载时间,相信大多数人都做过如下尝试   - Keep-alive: TCP持久连接,增加了TCP连接的复用性,但只有当上一个请求/响应完全 完成后,client才能发送下一个请求 - Pipelining: 可同时发送多个请求,但是服务器必须严格按照请求的先后顺序返回响 应,若第一个请求的响应迟迟不能返回,那后面的响应都会被阻塞,也就是所谓的队头 阻塞 - 请求合并:雪碧图,css/js内联.css/js合并等,然而请求合并又会带来缓存失效. 解析变慢.阻塞渲染.木桶效应等诸

题目链接: https://pan.baidu.com/s/1Utfq8W-NS4AfI0xG-HqSbA 提取码: 9wqs 解题思路: 打开流量包后,按照协议进行分类,发现了存在以下几种协议类型: ARP / DNS / FTP / FTP-DATA / ICMP / ICMPv6 / IGMPv3 / LLMNR / NBNS / SSDP / SSL / TCP / TLSv1.2 / UDP 按照协议类型诸葛数据包进行读取,发现只有FTP协议是由用的,但是同时注意到TLS协议是进行加密

本文来自网易云社区 之前有介绍<wireshark抓包分析--TCP/IP协议>,然后某天有人问我,示例里是HTTP的,如果是HTTPS,你可以抓包分析吗?基于好奇,我查阅了下相关资料,把一些浅见分享给大家.在讲HTTPS的解密之前先来看下HTTPS与HTTP的不同之处,HTTPS是在TCP/IP与HTTP之间,增加一个安全传输层协议,而这个安全传输层协议一般用SSL或TLS,类似于下图.即HTTPS=HTTP+SSL/TLS. SSL协议分为SSL记录协议层和SSL握手协议层.SSL握手协议