Gone With the Wind

什么是MTU?为什么MTU值普遍都是1500?

大学那会我玩魔兽世界,我的职业是法师,然后经常有朋友找我我带小号,带小号的方式是冲到血色副本里面把所有怪拉到一起,然后一起用AOE技能瞬间杀掉,在学校玩的时候没什么问题,但是放假在家的时候,我发现每次我拉好怪,放技能AOE的那个瞬间,很大概率会掉线,也不是网速问题,当时很多人也遇到同样的问题,看到个帖子说,把自己的MTU改成1480就行了,当时也不知道啥是MTU,就改了,发现还真的可以,就愉快地打游戏去了,多年以后我才知道MTU的重要性。

什么是MTU

Maximum Transmission Unit,缩写MTU,中文名是:最大传输单元。

这是哪一层网络的概念?

从下面这个表格中可以看到,在7层网络协议中,MTU是数据链路层的概念。MTU限制的是数据链路层的上层协议的payload的大小,例如IP,ICMP等。

OSI中的层 功能 TCP/IP协议族
应用层 文件传输,电子邮件,文件服务,虚拟终端 TFTP,HTTP,SNMP,FTP,SMTP,DNS,Telnet
表示层 数据格式化,代码转换,数据加密 没有协议
会话层 解除或建立与别的接点的联系 没有协议
传输层 提供端对端的接口 TCP,UDP
网络层 为数据包选择路由 IP,ICMP,RIP,OSPF,BGP,IGMP
数据链路层 传输有地址的帧以及错误检测功能 SLIP,CSLIP,PPP,ARP,RARP,MTU
物理层 以二进制数据形式在物理媒体上传输数据 ISO2110,IEEE802,IEEE802.2

MTU有什么用?

举一个最简单的场景,你在家用自己的笔记本上网,用的是路由器,路由器连接电信网络,然后访问了www.baidu.com,从你的笔记本出发的一个以太网数据帧总共经过了以下路径:

1
笔记本 -> 路由器 -> 电信机房 -> 服务器

其中,每个节点都有一个MTU值,如下:

1
1500     1500                 1500
笔记本 -> 路由器 -> 电信机房  -> 服务器

假设现在我把笔记本的MTU最大值设置成了1700,然后发送了一个超大的ip数据包(2000),这时候在以外网传输的时候会被拆成2个包,一个1700,一个300,然后加上头信息进行传输。

1
1700     1500                1500
笔记本 -> 路由器 -> 电信机房 -> 服务器

路由器接收到了一个1700的帧,发现大于自己设置的最大值:1500,如果IP包DF标志位为1,也就是不允许分包,那么路由器直接就把这个包丢弃了,根本就不会到达电信机房,也就到不了服务器了,所以,到这里我们就会发现,MTU其实就是在每一个节点的管控值,只要是大于这个值的数据帧,要么选择分片,要么直接丢弃。

为什么是1500?

其实一个标准的以太网数据帧大小是:1518,头信息有14字节,尾部校验和FCS占了4字节,所以真正留给上层协议传输数据的大小就是:1518 - 14 - 4 = 1500,那么,1518这个值又是从哪里来的呢?

假设取一个更大的值

假设MTU值和IP数据包大小一致,一个IP数据包的大小是:65535,那么加上以太网帧头和为,一个以太网帧的大小就是:65535 + 14 + 4 = 65553,看起来似乎很完美,发送方也不需要拆包,接收方也不需要重组。

那么假设我们现在的带宽是:100Mbps,因为以太网帧是传输中的最小可识别单元,再往下就是0101所对应的光信号了,所以我们的一条带宽同时只能发送一个以太网帧。如果同时发送多个,那么对端就无法重组成一个以太网帧了,在100Mbps的带宽中(假设中间没有损耗),我们计算一下发送这一帧需要的时间:

1
( 65553 * 8 ) / ( 100 * 1024 * 1024 ) ≈ 0.005(s)

在100M网络下传输一帧就需要5ms,也就是说这5ms其他进程发送不了任何数据。如果是早先的电话拨号,网速只有2M的情况下:

1
( 65553 * 8 ) / ( 2 * 1024 * 1024 ) ≈ 0.100(s)

100ms,这简直是噩梦。其实这就像红绿灯,时间要设置合理,交替通行,不然同一个方向如果一直是绿灯,那么另一个方向就要堵成翔了。

既然大了不行,那设置小一点可以么?

假设MTU值设置为100,那么单个帧传输的时间,在2Mbps带宽下需要:

1
( 100 * 8 ) / ( 2 * 1024 * 1024 ) * 1000 ≈ 5(ms)

时间上已经能接受了,问题在于,不管MTU设置为多少,以太网头帧尾大小是固定的,都是14 + 4,所以在MTU为100的时候,一个以太网帧的传输效率为:

1
( 100 - 14 - 4 ) / 100 = 82%

写成公式就是:( T - 14 - 4 ) / T,当T趋于无穷大的时候,效率接近100%,也就是MTU的值越大,传输效率最高,但是基于上一点传输时间的问题,来个折中的选择吧,既然头加尾是18,那就凑个整来个1500,总大小就是1518,传输效率:

1
1500 / 1518 =  98.8%

100Mbps传输时间:

1
( 1518 * 8 ) / ( 100 * 1024 * 1024 ) * 1000 = 0.11(ms)

2Mbps传输时间:

1
( 1518 * 8 ) / ( 2 * 1024 * 1024 ) * 1000 = 5.79(ms)

总体上时间都还能接受

最小值被限制在64

为什么是64呢?

这个其实和以太网帧在半双工下的碰撞有关,感兴趣的同学可以自行去搜索。

在我玩游戏的时候,为什么把MTU改成1480就不卡了?

路由器默认值大多都是1500,理论上是没有问题的,那为什么我玩游戏的时候改成1480才能流畅呢?原因在于当时我使用的是ADSL上网的方式,ADSL使用的PPPoE协议。

PPPoE

PPPoE协议介于以太网和IP之间,协议分为两部分,PPP( Point to Point Protocol )和oE( over Ethernet ),也就是以太网上的PPP协议,而PPPoE协议头信息为:

1
| VER(4bit) | TYPE(4bit) | CODE(8bit) | SESSION-ID(16bit) | LENGTH(16bit) |

这里总共是48位,也就是6个字节,那么另外2个字节是什么呢?答案是PPP协议的ID号,占用两个字节,所以在PPPoE环境下,最佳MTU值应该是:1500 - 4 - 2 = 1492。

我的上网方式

当时我的上网路径如下:

1
PC -> 路由器 -> 电信

我在路由器进行拨号,然后PC连接路由器进行上网。

最根本原因

问题就出在路由器拨号,如果是PC拨号,那么PC会进行PPPoE的封装,会按照MTU:1492来进行以太网帧的封装,即使通过路由器,路由器这时候也只是转发而已,不会进行拆包。

而当用路由器拨号时,PC并不知道路由器的通信方式,会以网卡的设置,默认1500的MTU来进行以太网帧的封装,到达路由器时,由于路由器需要进行PPPoE协议的封装,加上8字节的头信息,这样一来,就必须进行拆包,路由器把这一帧的内容拆成两帧发送,一帧是1492,一帧是8,然后分别加上PPPoE的头进行发送。

平时玩游戏不卡,是因为数据量路由器还处理得过来,而当进行群怪AOE的时候,由于短时间数据量过大,路由器处理不过来,就会发生丢包卡顿的情况,也就掉线了。

帖子里面提到的1480,猜测可能是尽量设小一点,避免二次拨号带来的又一次PPPoE的封装,因为时间久远,没办法回到当时的场景再去抓包了。

结论

1518这个值是考虑到传输效率以及传输时间而折中选择的一个值,并且由于目前网络链路中的节点太多,其中某个节点的MTU值如果和别的节点不一样,就很容易带来拆包重组的问题,甚至会导致无法发送。

前端如何获取主域名(根域名)

背景

最近项目中需要获取url的主域名,比如www.baidu.com那么就需要获取baidu.com,看似简单,.号分隔,取到最后两位就行,但是坑爹的是有xxx.com.cn这类域名,还有很多日本的域名,类似toei.aichi.jp等,这些都无法通过这种简单的取最后两位的方式来获取,看来只能枚举了。

Public Suffix List

这问题肯定是早有人就遇到了,于是各路有识之士已经帮你完整得准备好了一个列表,里面全部都是那些奇葩域名,一些jp域名也是让我长见识了,不知道各位老司机在秋名山飙车的时候有没有见过这些个域名:

1
秋田.jp
群馬.jp
香川.jp
高知.jp
鳥取.jp
鹿児島.jp
// jp geographic type names
// http://jprs.jp/doc/rule/saisoku-1.html
*.kawasaki.jp
*.kitakyushu.jp
*.kobe.jp
*.nagoya.jp
*.sapporo.jp
*.sendai.jp
*.yokohama.jp
!city.kawasaki.jp
!city.kitakyushu.jp
!city.kobe.jp
!city.nagoya.jp
!city.sapporo.jp
!city.sendai.jp
!city.yokohama.jp
// 4th level registration
aisai.aichi.jp

感兴趣的朋友可以看看这个github项目:https://github.com/wrangr/psl

这里有各种主域名的列表:https://publicsuffix.org/list/public_suffix_list.dat.

浏览器其实也有内置类似的东西,用来做域名判断,cookie存储之类的事宜。

pls的问题

问题看似好像解决了,已经有现成的脚本去获取,但是仔细一看这脚本竟然有将近200K,而我自己的脚本才10K,既然浏览器已经内置了pls,那浏览器有没有暴露内置接口呢?很遗憾,搜索了一下并没有,而且浏览器那么多,即使chrome暴露了,IE肯定没有,等等,刚刚好像我们说到浏览器用来做域名判断,cookie存储,那我们能不能用这类方式间接地去调用内置pls呢?

最终解决方案

目前想到有两种方式可以间接去调,document.doamindocument.cookie,测试一下就会发现,如果你尝试把当前域名设置为com.cn或者把cookie设置到com.cn上面,浏览器并不会生效,document.domain在第二次设置的时候,firefox会抛错,看来并不是很合适,而且可能多多少少会影响到业务,cookie设置方便,而且清除也方便,上代码:

1
function getMainHost() {
  let key  = `mh_${Math.random()}`;
  let keyR = new RegExp( `(^|;)\\s*${key}=12345` );
  let expiredTime = new Date( 0 );
  let domain = document.domain;
  let domainList = domain.split( '.' );

  let urlItems   = [];
  // 主域名一定会有两部分组成
  urlItems.unshift( domainList.pop() );
  // 慢慢从后往前测试
  while( domainList.length ) {
    urlItems.unshift( domainList.pop() );
    let mainHost = urlItems.join( '.' );
    let cookie   = `${key}=${12345};domain=.${mainHost}`;

    document.cookie = cookie;

    //如果cookie存在,则说明域名合法
    if ( keyR.test( document.cookie ) ) {
      document.cookie = `${cookie};expires=${expiredTime}`;
      return mainHost;
    }
  }
}

拉了差不多几十个pls里面的域名,跑了一下单元测试,没有问题。

iOS大保健 - 基础信息的收集

本文列出了各种iOS的基础信息的获取方式。

系统信息

  • 设备型号
1
struct utsname systemInfo;
uname(&systemInfo);
NSString *platform = [NSString stringWithCString:systemInfo.machine encoding:NSASCIIStringEncoding];
  • 操作系统名称
1
UIDevice *device = [UIDevice currentDevice];
[device systemName];
  • 操作系统版本
1
UIDevice *device = [UIDevice currentDevice];
[device systemVersion];
  • 设备型号,如: iPad,iPod等。
1
UIDevice *device = [UIDevice currentDevice];
[device model];
  • 屏幕分辨率
1
UIScreen *screen     = [UIScreen mainScreen];
CGSize screenSize    = [[UIScreen mainScreen] bounds].size;
CGFloat scale        = screen.scale;
int screenX          = screenSize.width * scale;
int screenY          = screenSize.height *scale;
NSString *resolution = [NSString stringWithFormat:@"%d*%d", screenX, screenY];
  • 电池电量
1
[UIDevice currentDevice].batteryMonitoringEnabled = YES;
[[NSNotificationCenter defaultCenter] addObserverForName:UIDeviceBatteryLevelDidChangeNotification object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification *notification) {
     // Level has changed
     NSLog(@"Battery Level Change");
     NSLog(@"电池电量:%.2f", [UIDevice currentDevice].batteryLevel);
 }];

网络信息

需要引入库:CoreTelephony.framework

  • 网络类型,如:WiFi,4G等。
1
NSString *networktype = nil;
NSArray *subviews = [[[[UIApplication sharedApplication] valueForKey:@"statusBar"] valueForKey:@"foregroundView"]subviews];
NSNumber *dataNetworkItemView = nil;
for (id subview in subviews) {
    if([subview isKindOfClass:[NSClassFromString(@"UIStatusBarDataNetworkItemView") class]]) {
        dataNetworkItemView = subview;
        break;
    }
}
switch ([[dataNetworkItemView valueForKey:@"dataNetworkType"]integerValue]) {
    case 0:
        networktype = @"UNKNOW";
        break;
    case 1:
        networktype = @"2G";
        break;
    case 2:
        networktype = @"3G";
        break;
    case 3:
        networktype = @"4G";
        break;
    case 4:
        networktype = @"LTE";
        break;
    case 5:
        networktype = @"Wi-Fi";
        break;
    default:
        break;
}
return networktype;
  • 蜂窝网络类型
1
CTTelephonyNetworkInfo *telephonyInfo = [[CTTelephonyNetworkInfo alloc] init];
if ( [telephonyInfo respondsToSelector:@selector(currentRadioAccessTechnology)] ) {
    id radioAccessType = [telephonyInfo performSelector:@selector(currentRadioAccessTechnology)
                                             withObject:nil];
    
    if ( [radioAccessType isKindOfClass:[NSString class]] ) {
        NSString *accessType = (NSString *)radioAccessType;
        if ( [accessType hasPrefix:@"CTRadioAccessTechnology"] && accessType.length >= 23 ) {
            NSString *accessTypeStr = [accessType substringFromIndex:23];
            return accessTypeStr;
        }
    }
}
    
return @"UNKNOW";
  • 运营商信息
1
CTTelephonyNetworkInfo *telephonyInfo = [[CTTelephonyNetworkInfo alloc] init];
CTCarrier *carrier    = [telephonyInfo subscriberCellularProvider];
NSString *carrierName = [carrier carrierName];
if ( nil != carrierName ) {
    return carrierName;
}
return @"UNKNOW";

应用状态

  • APP启动,或者由后台进入前台
1
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationBecomeActive) name:UIApplicationDidBecomeActiveNotification object:nil];
  • APP从后台进入前台
1
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationBecomeActive) name:UIApplicationWillEnterForegroundNotification object:nil];
  • APP进入后台
1
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(applicationEnterBackground) name: UIApplicationDidEnterBackgroundNotification object:nil];
  • APP在前台锁屏
1
#import <notify.h>
#define NotificationLock CFSTR("com.apple.springboard.lockcomplete")
#define NotificationChange CFSTR("com.apple.springboard.lockstate")
#define NotificationPwdUI CFSTR("com.apple.springboard.hasBlankedScreen")

static void screenLockStateChanged(CFNotificationCenterRef center,void* observer,CFStringRef name,const void* object,CFDictionaryRef userInfo)
{
	NSString* lockstate = (__bridge NSString*)name;
	if ([lockstate isEqualToString:(__bridge  NSString*)NotificationLock]) {
	    NSLog(@"locked.");
	} else {
	    NSLog(@"lock state changed.");
	}
}

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
	CFNotificationCenterAddObserver(CFNotificationCenterGetDarwinNotifyCenter(), NULL, screenLockStateChanged, NotificationLock, NULL, CFNotificationSuspensionBehaviorDeliverImmediately);
	CFNotificationCenterAddObserver(CFNotificationCenterGetDarwinNotifyCenter(), NULL, screenLockStateChanged, NotificationChange, NULL, CFNotificationSuspensionBehaviorDeliverImmediately);
	return YES;
}
  • APP在后台锁屏,通过循环的方式检测
1
static void setScreenStateCb()
{
uint64_t locked;

__block int token = 0;
notify_register_dispatch("com.apple.springboard.lockstate",&token,dispatch_get_main_queue(),^(int t){
});
	notify_get_state(token, &locked);
	NSLog(@"%d",(int)locked);
}

- (void)applicationDidEnterBackground:(UIApplication *)application
{
	while (YES) {
	    setScreenStateCb();
	    sleep(5); // 循环5s
	}
}
  • 获取当前APP的CPU使用率
1
kern_return_t kr;
task_info_data_t tinfo;
mach_msg_type_number_t task_info_count;
    
task_info_count = TASK_INFO_MAX;
kr = task_info(mach_task_self(), TASK_BASIC_INFO, (task_info_t)tinfo, &task_info_count);
if (kr != KERN_SUCCESS) {
    return;
}
    
task_basic_info_t      basic_info;
thread_array_t         thread_list;
mach_msg_type_number_t thread_count;
    
thread_info_data_t     thinfo;
mach_msg_type_number_t thread_info_count;
    
thread_basic_info_t basic_info_th;
uint32_t stat_thread = 0; // Mach threads
    
basic_info = (task_basic_info_t)tinfo;
    
// get threads in the task
kr = task_threads(mach_task_self(), &thread_list, &thread_count);
if (kr != KERN_SUCCESS) {
    return;
}
if (thread_count > 0)
    stat_thread += thread_count;
    
long tot_sec = 0;
long tot_usec = 0;
float tot_cpu = 0;
int j;
    
for (j = 0; j < thread_count; j++)
{
    thread_info_count = THREAD_INFO_MAX;
    kr = thread_info(thread_list[j], THREAD_BASIC_INFO,
                     (thread_info_t)thinfo, &thread_info_count);
    if (kr != KERN_SUCCESS) {
        return;
    }
    
    basic_info_th = (thread_basic_info_t)thinfo;
    
    if (!(basic_info_th->flags & TH_FLAGS_IDLE)) {
        tot_sec = tot_sec + basic_info_th->user_time.seconds + basic_info_th->system_time.seconds;
        tot_usec = tot_usec + basic_info_th->system_time.microseconds + basic_info_th->system_time.microseconds;
        tot_cpu = tot_cpu + basic_info_th->cpu_usage / (float)TH_USAGE_SCALE * 100.0;
    }
    
} // for each thread
    
kr = vm_deallocate(mach_task_self(), (vm_offset_t)thread_list, thread_count * sizeof(thread_t));
assert(kr == KERN_SUCCESS);
    
NSLog(@"CPU Usage: %f \n", tot_cpu);
  • 获取当前APP的内存使用情况
1
task_basic_info_data_t taskInfo;
mach_msg_type_number_t infoCount = TASK_BASIC_INFO_COUNT;
kern_return_t kernReturn = task_info(mach_task_self(),
                                     TASK_BASIC_INFO, (task_info_t)&taskInfo, &infoCount);

if(kernReturn != KERN_SUCCESS) {
    return;
}
    
NSLog(@"Memory Usage: %f", taskInfo.resident_size / 1024.0 / 1024.0);

零门槛学习https--(5)常见的https攻击原理

上一篇:零门槛学习https–(4)https协议详解

看似毫无破绽的TLS协议,其实也存在着诸多漏洞,主要因为TLS协议太复杂了,复杂的东西必然会出现漏洞,下面我们来看看一些常见的攻击手段有哪些,以及一些攻击实例。

伪造证书

攻击原理

这是一种中间人攻击,就是伪造网站证书,虽然浏览器会提示访问了不安全的网址,但是大部分对https没什么了解的人基本都会选择忽略问题继续浏览,这是一种简单,成本低,且效果还可以的攻击方式。

防御方法

打开浏览器设置,如果证书不可信,那么就直接不能访问。这个其实也不能算是TLS的漏洞,只能说是浏览器为了做兼容而没有采取一些强制性措施,或许不久的将来,浏览器默认就会直接拒绝无效证书的连接。

POODLE

攻击原理

上一章看TLS协议的时候,我们看到,因为要处理兼容性问题,客户端和服务端不得不支持很多种加密套件和TLS或者SSL版本,由此,衍生一个问题就是:一些老久的加密套件或者SSL版本通常在现在的计算能力下安全性没那么高,或者早先的协议是有安全漏洞的,所以,针对SSL降级,还有加密降级攻击就成了一种主流的攻击方式。

POODLE的全称是Padding Oracle On Downgraded Legacy Encryption,由谷歌的工程师在2014年发现了这个问题,问题的主要原因在于分块加密。其原理是:

AES 分块加密在原文内容长度不满足时,会在原文后面填充一些内容,保证每个分块的长度一致,这就是Padding Oracle,也是攻击的关键,因为新版TLS不存在这个问题,所以我们需要对协议进行降级,而降级就是Downgraded Legacy Encryption,所以这也是这个漏洞名称的由来。

协议降级很简单,只要在客户端发送Client Hello消息的时候,把客户端支持的加密套件替换成SSL3.0,如果服务端支持,那么后续连接就会使用SSLV3来进行连接,具体的Padding Oracle攻击原理可以看一下这篇文章,写得非常详细。

防御方法

客户端禁用SSLV3协议,服务端也关闭SSLV3的连接。

FREAK

这个攻击方式可以说到一个很有意思的事情,目前基本主流的加密算法都是由美国开发的,90年代的时候,NSA为了能够监听世界上所有的网络通信,出台了对于软件出口规定,规定只有美国境内能够使用高强度的RSA加密,对于出口国外的软件,最高允许512密钥长度的RSA,高安全级别的加密算法被认为是战争武器而禁止对外出口。2000年之后,美国逐渐放宽了这个限制,目前美国任然有一些带有加密算法和函数的软硬件受到出口管制。

攻击原理

由于历史遗留原因,IE6,网景,甚至是手机上的安卓和iOS Safari 浏览器,都支持512密钥长度的RSA加密,这在2015年的时候才被法国工程师发现。据说在当时任然有38%的服务器还支持512长度的密钥,而且讽刺的是,美国一些政府部门网站也存在此漏洞。

攻击者在Client Hello的时候,把高强度的密钥加密算法都剔除掉,留下低强度的算法,如果服务端也支持低强度的加密算法,那么就会选择这一算法。虽然在90年代一般的PC还无法破解512长度密钥,但是目前个人已经完全有能力破解了。

防御方法

苹果已经在当时推出相应补丁,而安卓也在后续版本进行了升级。服务端应该禁止低强度加密算法。

HTTPS Strip

也称为SSLStrip,是一种基于社会学的攻击方法,也是中间人攻击的一种,和任何加密方式都无关,和SSL也无关,也是目前为止我成功实施的一种攻击方式。

攻击原理

通常,我们在浏览器访问一个网址的时候,会直接输入网址,而不会关注协议,比如我要访问天猫,那么我就会输入:tmall.com,而此时浏览器默认会使用http协议访问,因为浏览器并不知道服务端是否开启了https,所以,攻击者直接劫持http访问,然后自己去访问https://www.tmall.com,并把内容通过http协议返回给浏览器,浏览器成功收到数据,就直接开始渲染页面,浏览器端完全就是访问一个http站点。所以,这种攻击方式就叫做SSL剥离攻击。除了浏览器之外的场景,基本不会受到此攻击的影响。

防御方法

HSTS(HTTP Strict Transport Security),这是一种浏览器技术,在客户端访问站点的时候,如果检测到当前域名在HSTS列表中,那么直接使用https协议访问,也就不会被攻击者劫持了。那么如何加入HSTS列表呢?在浏览器第一次访问站点的时候,站点可以在http返回头里面来标示是否启用HSTS,还有过期时间。

这是第一次访问www.taobao.com的场景,http返回头有个:Strict-Transport-Security属性,过期时间是一年。

这是第二次访问www.taobao.com时候,因为已经在HSTS列表中,就直接是一个Internal Redirect,不会请求服务端。

其实你会发现,浏览器第一次访问网站的时候,也是有可能被劫持的,所以现在有些网址会内置在浏览器的HSTS列表中,防止第一次访问被劫持的情况发生。不久的将来,也许浏览器就默认使用https访问,这种攻击方式也就无法发挥作用了。

攻击实例

写个脚本就可以检测网站是否开启了HSTS,对于没有开启HSTS的网站都可以发动攻击。以下是我对tmall.com发起的一次http strip的攻击实例。

1
上图中看到访问tmall.com的跳转逻辑是:
	tmall.com --302--> www.tmall.com --301--> https://www.tmall.com。

301还好,现代浏览器几乎会作为永久缓存,这种情况下如果不清除缓存,其实跟HSTS效果差不多。
302就坑了,基本是不会缓存的。

1
从上图中我们可以看到返回头中虽然包含了STS头,但是过期时间为0

也就是不开启HSTS,用了一个301跳到了https站点

下面我开始准备需要的东西,当然一个前提是你要能捕获流量:

  1. 为了方便我使用本机测试,可以建个DNS服务器,也可以使用更简单的host文件,我选择使用host文件,把tmall.comwww.tmall.com指向127.0.0.1。实际情况中,可以采用ARP欺骗等方式获取局域网流量。
  2. 在本机建立一个web server,具体的代码就不贴了,后面贴一些关键代码。

好,我们可以开始攻击了,具体步骤如下。

  1. 首先使用浏览器访问tmall.com,因为没有开启HSTS,浏览器开始用http方式请求tmall.com
  2. 这时候本次请求已经到我的中间人server,然后server使用IP方式访问真实的tmall.com,这里不能用域名,因为域名已经指向本机了。
  3. 拿到真实tmall.com的返回之后,添加如下代码:

    1
    body += '<script>alert( 'hello' )</script>';
  4. 返回给浏览器,此时,浏览器看起来是这个样子,弹出了hello,并且仔细看会发现https标示没有了,如果不弹出alert,天猫那个具有强烈视觉冲击感的页面,很容易让你忽略https标示没有了这件事。

  5. 再进一步看看,点击登陆按钮的跳转逻辑是:<a href="//:login.tmall.com">登陆</a>,没有写死协议,如果写死了协议,在返回内容的时候,手动替换为http即可。登录页同样没有开启HSTS,我们试试看能不能拿到账号密码。简单分析一下天猫登录页,真正账号密码的输入框采用的是login.taobao.com提供的iframe登录框,有二维码和手动输入账号密码两个选项,二维码无能为力了,看看能不能拿到手动输入账号密码时的内容。
  6. 看了看login.taobao.com,没有写死协议,并且发现同样没有开启HSTS,这就好办了,和tmall.com一样,拦截请求,并在返回内容添加如下代码,插入一个jQuery,并在在输入密码的时候获取输入事件:

    1
    body += 
     "<script src=\"https://code.jquery.com/jquery-latest.js\"></script>" +
     "<script>" +
       "$( '#TPL_username_1' ).on( 'input', function (){" +
         "console.log( this.value );" +
       "} );" + 
       "$( '#TPL_password_1' ).on( 'input', function (){" +
         "console.log( this.value );" +
       "} );" +
     "</script>";
  1. 运行脚本,看看效果:

    login.taobao.com竟然是GBK编码的,导致乱码了,这里我懒得转编码了,可以看到左上角其实浏览器已经显示了不安全三个字,同样估计很少有人会看到这几个字。我们尝试输入一下账号密码试试看:

    已经打印出账号密码,发个请求就能发送到我自己的服务器了,后面再跳回到https站点就神不知鬼不觉了。

  2. 总的来说,本次攻击的需要的条件其实是比较多的,首先因为http://www.tmall.com跳转到https://www.tmall.com是301跳转,而chrome等浏览器把301几乎是当做永久缓存来处理的,除非手动清理缓存,当然很多浏览器对301也不缓存,或者重启就没了。其次,默认的登陆方式是二维码登陆,二维码登陆就无法实施此次攻击了。不过基于天猫访问量巨大,符合条件的流量估计也不少,而且http://login.taobao.com跳往https站点是302,也就是不会缓存了,这个有安全隐患。如果某天天猫开启了HSTS,那么这类攻击就几乎无法生效了,毕竟这对天猫来说也就是一个配置项的事。

其他漏洞

  1. 完全信任证书漏洞。很多android APP采取了不校验证书的方式,导致中间人攻击非常容易,比如早先的亚马逊官方APP、携程APP等。
  2. Heartbleed。OpenSSL在实现心跳的扩展没有对输入进行适当验证,导致过读,可以读取服务器内存中的内容,即使协议没问题,实现有问题同样也会造成漏洞的产生。

总结

TLS因为比较复杂,所以或多或少总会有些漏洞,TLS也在慢慢地不断完善,因为很多东西基于数学原理,或者某天出现了快速因式分解等的方法,瞬间就可以破解TLS,也有人说美国安全局其实早就已经掌握某些技术能够监听全世界的加密流量了,加密和破解总是在不断地博弈,在博弈过程中进行自我升级,随着技术的发展以及大家对隐私和网络安全越来越关注,相信我们的网络环境一定会变得越来越安全。

零门槛学习https--(4)https协议详解

上一篇:零门槛学习https–(3)https的安全策略

https其实就是在TLS之上的http协议,所以各种头信息以及数据格式和http其实都一样,主要区别就在TLS,下面我们来看看TLS是如何工作的。

本章咱们讨论一下TLS的一个整体思路,和一些重要的细节,所有的细节请参看RFC文档

TLS握手

和TCP的握手一样,TLS在工作之前也需要握手,保证客户端和服务端的正确运行,下面的图片里面包含了TLS握手的整个过程。

下面是一次对https://www.baidu.com请求的TLS握手过程,我们结合上面的图一起来看看整个过程在实际连接中是什么样子的。

Client Hello

和TCP握手一样,客户端首先要告知服务端自己的来意,总共会传递以下信息:

1
1. 客户端支持的TLS协议版本,这里会有一个list,目前主流的是TLS1.2。
2. 一个随机数,我们记为CR,具体的作用是用来生成对话密钥,我们稍后会用到。
3. 支持的加密方法套件。例如:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,由四个部分组成:
    1. 密钥交换算法。用来交换对称加密密钥的算法。
    2. 加密算法。对称加密算法,真正的加密通讯内容的加密算法。
    3. 报文认证信息码(MAC)算法。对通讯内容做一个摘要,然后附加到每一段消息尾部,
       这样服务端就知道消息是否被更改。这一步要防止的是:虽然加密了,但是如果中间人随便更改一个字节,
       也许要表达的内容就不一样了。
    4. PRF(伪随机函数)。
4. 支持的压缩方法。
5. 扩展信息。扩展信息会有非常多,类似时间戳,域名等等信息,具体的可以参看RFC文档。

有一个扩展信息可以提一下,早先的TLS协议是没有域名信息的,造成一个问题就是,如果服务端采用一些虚拟化技术虚拟了很多主机,每个主机服务不同的域名,这时候有客户端向服务端发出TLS请求,服务端这时候并不知道应该把哪个证书返回,所以为了解决这个问题,在2006年TLS协议加入了域名扩展信息。

所以说,如果你在公司上网,即使你使用了HTTPS,公司依然能够知道你访问是t66y还是115,或者是taobao。有人也向官方指出这会泄露隐私,但是官方认为这是一个低安全级别问题,并且现在还没有什么好的解法,所以这个问题就搁置了。

1
红框中分别是:

1. 客户端随机数:CR。
2. 本次请求的域名。
3. 扩展信息,要求服务端直接返回证书的校验结果,校验方式是:OCSP。

Server Hello

1
1. 确认TLS协议的版本,如果客户端的协议服务端不支持的话,服务端会选择关闭这个连接。
2. 从客户端支持的加密方法中,选择一个加密方式,并告知客户端。
3. 生成一个随机数,我们记为SR,后续我们会结合CR生成对话密钥,稍后会用到。
4. 从客户端支持的压缩算法中,选择一个压缩算法。

1
红框中内容分别是:

1. 服务端随机数:SR。
2. Session Id。跟SSO的cookie的概念有点类似,就是当你这次握手成功之后,
   下次直接带上这个session Id,如果服务端认为合法,那么就不用再进行握手,
   直接可以开始用之前已经商量好的对称加密密钥开始通信了。
3. 服务端选择的加密套件。
4. 服务端设置了`status_request`的应答标志位,答应客户端会直接返回服务端证书的OCSP校验结果。

Server Certificate

这一步主要是返回证书链供客户端验证。

服务端返回了证书链,里面包含三张证书。

[Certificate Status]

这一步也是可选的,当Client Hello的时候,客户端会在extension里面要求服务端直接返回证书的校验结果,以加快访问速度,这是TLS的一个扩展,在RFC6066中规定了这一个扩展。当然即使客户端要求了,服务端在Server Hello的时候应答了,服务端也可以不返回,这样客户端就要自己去校验了。

服务端会返回OCSP验证的结果,这样,服务端可以缓存OCSP的结果,服务端就无需再次访问OCSP获取证书验证结果,提高客户端的访问速度。

说的直白一点,这一步的作用就是:服务端返回证书给客户端,然后再告诉客户端说,这个证书我已经验证过了,你放心用吧。客户端会选择信任中间证书,直接校验根证书,所以,这里即使被中间人攻击直接返回验证成功,但是因为客户端任然会通过操作系统内置的根证书来进行验证,这一步任然是安全的。

这里返回了OCSP的结果:successful。

[Server Key Exchange]

这一步也是可选的,取决于双方的加密方法,这里就不得不提到TLS的两种密钥协商方式:

  1. TLS_RSA_XXXX。这类算法里面,RSA的作用是Key Transmission,也就是说对称加密的密钥是由客户端生成,然后通过证书里面的公钥加密发送给服务端。如果采用的是RSA算法,那么这一步就不需要了。
  2. TLS_DHE_XXXX。这类算法里面,使用DH算法进行密钥协商,DH的作用就是Key Exchange,密钥是由客户端和服务端共同生成的。

DH密钥协商可以总结如下:

1
1. 通讯双方(张三、李四)需要先约定好算法参数(algorithm parameters):一个素数 p 作为模数,一个素数 g 作为基数(g 也称为“生成元”)。这两个算法参数是可以对外公开滴。
2. 对于张三而言,需要先想好一个秘密的自然数 a 作为私钥(不能公开),然后计算 A = ga mod p 作为自己的公钥(可以公开)。
3. 对李四而言也类似,先想好一个秘密的自然数 b 作为私钥(不能公开),然后计算 B = gb mod p 作为自己的公钥(可以公开)。
4. 张三和李四互相交换各自的公钥。
5. 然后张三计算出 k = Ba mod p,李四计算出 k = Ab mod p

1
上图中,服务器端把p、g还有服务端算出的DH公钥,组合成Pubkey,
用SHA512求得hash之后,用服务端私钥做RSA签名防伪。

客户端收到后,会用证书里面的公钥解密,验证签名正确性,然后拿出服务端DH公钥

[Client Certificate Request]

这一步也是可选的,要求客户端出示自己的证书,默认服务端不会向客户端索取证书。主要用于银行等金融领域,只有持有相应的证书(各类U盾)才允许客户端访问自己的网络,这里的客户端证书和CA证书类似,不过签发的一方通常是银行自己。

Server Done

这一步就是个标志位,告诉客户端,整个Server Hello阶段已经结束,轮到你回消息了。

Client Certificate

如果Server Hello的时候,服务端要求验证客户端证书,客户端会在这里给服务端发送自己的证书。

这是客户端在Server Hello Done之后发送的第一条数据。

Client Key Exchange

这条消息必须在Client Certificate(如果有的话)之后立即发送。这里的Key Exchange交换的就是pre-master key,有了pre-master key和我们之前生成两个随机数CRSR就能够计算出我们的对称加密的密钥了,这里总共分为两种情况:

  1. 如果采用的是RSA算法,这里就是一个客户端产生的48 byte的随机数,用服务端的公钥加密之后发送。这里需要用公钥加密的原因在于,前两个随机数都是明文传输的,而采用RSA方式传输密钥,如果三个随机数都是明文,那么就可以计算出对称加密的密文了,所以这里一定是要加密传输。
  2. 如果采用的是DH算法及各种变种算法(如:ECDHE),这里发送的就是客户端公钥。这个消息不用公钥加密,原因在于DH算法本身的作用就是在不安全的通信通道交换一个安全的加密密钥,真是的一个神奇的算法。

这里把DH算法的客户端公钥发送给服务端。

至于为什么不能全部都由客户端或者都由服务端生成呢?这里引用别的地方看到的一段话,解释得非常清楚:

1
不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。
由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,
三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,
如果随机数不随机,那么pre master secret就有可能被猜出来,
那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,
那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,
一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,
每增加一个自由度,随机性增加的可不是一。

总得来说即使客户端或者服务器端被人做了手脚,采用的随机数生成函数变成了可控的随机,那么只要另外一方不是被同一人做手脚,整体通信任然是安全的。

Change Cipher Spec(客户端)

这一步就是个标志位,告诉服务端:客户端之后通信就开始使用之前约定好的加密方式来加密传输了。

Encrypted Handshake Message(客户端)

这一步的作用是把之前握手的所有消息,用加密套件里的hash算法计算出一个值,然后用刚刚协商好的对称加密的密钥进行加密,发送给服务端,即能验证之前发送的消息有没有被篡改,又能验证下服务端计算的密钥对不对,如果计算不对就解不出明文。

因为内容已经加密了,就看不到具体的东西了

Change Cipher Spec(服务端)

跟客户端一样,一个标示位,告诉客户端:服务端之后通信就开始使用之前约定好的加密方式来加密传输了。

Encrypted Handshake Message(服务端)

同样的,把之前发送的所有东西都计算hash,然后用自己计算出来的对称加密密钥加密,发送给客户端解密。至此,服务端在握手阶段就结束了。客户端在收到消息,并且解密验证通过了之后,客户端也就结束了。

TLS 数据传输

总得来说跟HTTP差不多,只是在每个包后面添加了一个由报文认证信息码(MAC)算法计算出来的hash,保证信息传输的健全性。

数据传输协议的是http

TLS session id

这个其实和SSO 登陆的cookie类似,有了cookie,第二次访问的时候服务端会去校验cookie是否有效,如果有效那就不用重新登陆了,如果cookie无效,那么就要重新登陆了。

session id也是如此,整个TLS握手过程还是比较复杂的,如果每个连接都这么握手一次,那体验也真是太差了,所以TLS设计了session id的概念,如果session id没有过期,那么就可以跳过握手阶段,直接开始加密传输。

所以有时候我们会发现,第一次访问某个HTTPS网站的时候很慢,但是第一次打开之后,第二次刷新,速度就很快了。

好了,到这里我们的TLS协议就介绍得差不多了,其实TLS协议还有非常多的细节,大家可以仔细参看RFC文档。TLS协议看起来似乎很完美,无法破解,但是现实中还是有很多基于TLS的攻击方式,下一篇就给大家来分享一下:

零门槛学习https–(5)常见的https攻击原理

零门槛学习https--(3)https的安全策略

上一篇:零门槛学习https–(2)https中s的秘密

上一篇我们已经把非对称加密RSA算法的原理已经摸清楚了,有了加密算法,我们就能够开始加密了。当然非对称加密还有好几种,这里我们只讨论RSA

RSA算法的局限性

在RSA的加密原理中,我们看到对明文m的要求是:

  1. m必须是整数。
  2. m必须小于n。

第一个条件很容易满足,文字可以转成arcii,而二进制文件没有小数。问题在第二个条件,通常n的选择是2048位,所以这也就意味着我们每加密一次的数据,二进制长度不得超过2048位,这个局限性就比较大了,因为 2048 / 8 = 256,也就是一次最多只能加密256 byte的东西,所以超出部分就只能分片加密了,而每次加密其实涉及到的计算量还挺大的,都是大数的幂次方计算,所以,如果在一个https请求中,完全采用RSA加密,那么客户端和服务端的计算量简直不可想象,特别是服务端,会造成用户体验异常低下。

非对称加密的解决办法

这里我们已经有了相对来说能够保证安全的方式,但是其计算量太大导致无法大规模应用,其他非对称加密的计算量同样非常大,那么,只能另寻他法了,剩下的算法就只有对称加密和摘要算法了,摘要算法不可逆,加密了之后就没法解了,肯定不适合,那么就只剩下对称加密了。

对称加密

之前我们没有直接用对称加密的原因是因为,如果对称加密的秘钥写死在客户端里面,那么很容易就被人拿到了,如果每次都随机生成,那么无法用加密的方式分发到对方手中。

结论

聪明的革命先烈们这时候就想到了,那我们用非对称加密来加密对称加密的密钥,然后用对称加密不就行了么?这样既避免了非对称加密的庞大的计算量,又能够避免对称加密的密钥被泄露,完美地解决了这个问题。

新的问题出现

上面的解决方案看起来似乎很完美,很快大家都开始实装,代码跑起来没有问题,加密解密也成功得运行了,而且当有人尝试拿到密文,也无从下手解密,突然,人们意识到一个问题:

MIM(man in the middle)中间人攻击

有个很常见的场景,假设用户A通过B的网关上网,那么A的所有流量都会经过B,也就是B能看到A的所有进出的流量,RSA在算法层面虽然没法破解,但是有人想到,RSA任然存在一个传递公钥的过程,并且这是明文的,那么就有如下场景:

1
1. A和服务器S进行通信,并且由S生成公钥和私钥,并在连接建立后,S把公钥给A。
2. 因为A经由B上网,也就是说S的公钥是经由B交给A的。
3. 这个时候,B可以伪装成服务端S1接受A的连接,并生成自己的公钥和私钥,再伪装成客户端C向S发送请求。
4. S把公钥给了B,B再把自己的公钥给A,所以就变成了:
5. A和B通信,B再和S通信,A虽然加密了,但是是用的B的公钥,所以B有私钥能够解密,然后再用S的公钥加密,发送给S,S任然能解密。
6. 整个过程神不知鬼不觉,B就悄悄查看了所有的通信内容
7. 甚至有可能在A申请把自己网银里面的钱转给D时,B也可以偷偷改成自己的,S认为这是A发出的,就把钱转给了B。

问题的原因

显然,人们深刻地认识到,因为数据的可复制性,无论是什么算法,都无法改变数据会被中间人窥探甚至修改的问题(以后量子加密的出现或许能解决这个问题,因为量子一旦被观测,叠加态就会坍缩,接收者就能够知道自己接收到的数据是否被窥探了)。

问题源于生活,那么在生活中一定可以找到答案。你把钱给了银行,银行给你承诺,你想用钱的时候一定会还给你,银行在这里承担了一个被所有人信任的角色,在计算机里面其实也一样,于是,人们为计算机通信引入了一个第三方:CA(Certificate Authority)。

数字证书

CA又称为证书颁发机构,主要用于颁发数字证书,用一个无法篡改的数字证书来表明身份,防止数据在通讯过程中被篡改和窥探,数字证书通常分为以下几种:

  1. 个人身份证书。
  2. 企业或机构身份证书。
  3. 支付网关证书。
  4. 服务器证书。
  5. 企业或机构代码签名证书。
  6. 安全电子邮件证书。
  7. 个人代码签名证书。

数字证书如何生成?

  1. 首先,CA要生成一个自己的公钥和私钥,这里通常只生成一次就行了。
  2. 有人向CA申请证书,把自己的各种身份信息,营业执照,域名,到期时间等等的信息发给CA。
  3. CA严格审核申请者的信息,申请通过后,CA为申请者生成一对公钥和私钥(也可以自己生成),把CA的签发人、地址、签发时间、过期失效时间等信息,加上申请者的基本信息以及DNS、域名、公钥等基本信息整合到一起,生成一个证书,这里的证书还未签名,仅仅是很多信息的聚合而已。
  4. 通过通用的摘要算法(通常是sha256)将信息摘要提取出来,然后用CA的私钥加密,这里因为私钥严格保存,所以别人无法伪造签名,除非拿到私钥。
  5. 把上一步计算出来的信息摘要附加到第三步生成的证书中,之后,这个证书就称为了一个被CA签名过的证书了,因为私钥被CA严格保存,所以没有人能够模仿CA的签名,这也就是签名安全的根本了。
  6. 服务端把这个证书挂到自己的服务器上去,就能够供人使用了。

以上整个过程称为:Public Key Infrastructure(PKI,公开密钥基础建设)

如何验证证书的有效性呢?

  1. 客户端向服务端发起请求,服务端返回数字证书。
  2. 客户端拿到证书之后,首先解析证书,拿到被私钥加密的摘要密文,然后再拿出证书的元数据。
  3. 用CA的公钥进行解密,CA的公钥是公开的,任何人都可以获取(会内置在操作系统里面,或者在CA的官方网站中可以获取),解密后拿到摘要的原文。
  4. 对元数据再次执行摘要算法,拿到摘要信息,然后和第三步的结果进行对比,只有当结果一致的时候,才认为证书是有效的。

整个过程可以理解为下图:

如果我们获取CA的公钥的时候,已经被替换了怎么办?

设想一下,当我们获取CA公钥的时候,已经被人替换了,这时候真正的证书反而没法解析,只有被伪造的证书才能被解析了,这里就有了证书链的概念。

证书链

通常在一个证书链中包含以下三种结构:

  1. end-user。终端用户,也就是https中真正用来加密通信的证书。
  2. intermediates。给end-user签发证书的CA的证书,主要用来校验end-user的证书是否合法的证书。
  3. root。root也是CA证书,区别在于,root证书是给intermediates签发证书的,用来校验intermediates的合法性。

证书链的签发。

  1. 首先,root自己先生成一对公钥和私钥,然后用自己的私钥给自己自签名,因为root的绝对信任。
  2. 二级CA向root申请证书,root按照上面提到的数字证书的生成方式,先给CA生成一对公钥和私钥,然后
  3. 把CA的各种信息算出摘要,再用自己的私钥加密,加上给二级CA生成的公钥,就组成了一张CA的证书。
  4. 然后有用户向二级CA申请证书时,按照这个步骤一步步签发,就形成了证书链。
  5. 证书一级一级签发,中间无法伪造,因为root证书的绝对安全,保证了整个证书链的安全。
  6. 证书链是有长度限制的,root颁发证书的时候会添加此字段,所以证书申请者无法再为别人签发证书。

CA的类型

上面提到intermediates和root都是CA证书,所以CA其实也就分为root CAs和intermediates CAs,root CAs可以认为是一个品牌,而intermediates CAs则是真正使用这个品牌生产产品的企业,举个例子:

1
哇哈哈母公司,拥有哇哈哈品牌,但是并没有自己的产品,做的只是给子公司授权品牌,也就是root.
子公司A,生产矿泉水,是一个intermediates.
子公司B,生产八宝粥,是一个intermediates.
子公司C,生产橙汁,也是一个intermediates.

为什么不能用root CA的私钥直接签名?

主要还是从安全性上考虑,私钥是需要放到服务器上去做签名用的,所以不可避免可能服务器会被人攻破,导致私钥泄露,所以root的私钥隔离得越远越好,如果某个intermediates的私钥被窃取了,那么用root的私钥再签发一个intermediates证书即可,不会威胁到整个root证书下所有人的安全。root CA的私钥一般锁在大金库里面,完全得物理隔离,以下是godaddy对这个的解释:

intermediate certificates are used as a stand-in for our root certificate. We use intermediate certificates as a proxy because we must keep our root certificate behind numerous layers of security, ensuring its keys are absolutely inaccessible.

root证书的获取

回到我们最初的问题,获取证书的时候就已经被替换了怎么办?这里我们只需要保证root证书的获取没有问题,那么只要其他中间证书被替换,最后校验root证书这里还是没法通过,那么如果保证root证书的获取是安全的呢?

  1. 首先,成为一个CA的一个前提是你要向微软等操作系统厂商申请加入他们的白名单,就是把自己的root证书内置在操作系统里面,随着系统的安装和升级的过程就已经被安装到操作系统里面。
  2. 浏览器等终端在验证的时候,就直接调用操作系统的接口,获取证书,用来验证,例如chrome和ie。
  3. 有些浏览器类似firefox有一套自己的证书系统,是随着安装firefox的时候,安装到本地,这样,即使操作系统的证书被篡改了,firefox依然有能力验证证书的有效性。

root证书并不会很多,目前主流的基本就只有:Symantec(VeriSign/GeoTrust)、Comodo、GoDaddy,也是被这几家垄断,签发证书躺着赚钱,所以现在也有一些公益的组织开始提供免费证书。

CRL(Certificate Revocation List)

CRL是证书吊销列表,早先的浏览器通过这种方式把这个列表缓存在本地,用以验证证书是否有效。但是因为客户端时间不可控,所以这种方式还是存在一定的风险。

OCSP协议(Online Certificate Status Protocol)

除了CRL的方式,还有一种在线证书状态协议OCSP,验证的时候会从CA直接获取验证结果,主要用于证书过期吊销等的验证,主流浏览器都已经支持,可以防止因为缓存或者客户端时间不正确导致的证书过期时间判断不准确的问题。

如何验证二级CA的证书?

浏览器和操作系统里面只内置了根证书,那么那些二级CA的证书又该如何验证呢?

这里有两种情况:

服务端没有返回中间证书

我们来看看谷歌的证书:

证书颁发机构信息访问,这一栏里面标示了此证书的证书颁发机构如何访问和验证,标红框的地址就是CA的证书下载地址,下面还有OCSP协议的验证地址。

服务端返回了中间证书

比较适用于实际情况,因为上一种情况会产生额外的http请求,访问速度就会比较慢了。

这里返回了三个证书:

证书链类似下面这样,可以自由配置:

1
-----BEGIN CERTIFICATE-----
自己的crt证书
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
父级的crt证书
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
父级的父级crt证书
-----END CERTIFICATE-----

end-user证书的类型

申请者能够申请的证书种类非常多,价格相差也很大,主要有以下几种:

  1. OV(Organization Validation SSL),以某个组织为维度签发证书,通常这都是一个公司,域名采用通配符的方式来签发,以适应组织业务的灵活发展,例如:*.tmall.com
    ,也就是任何tmall.com的三级域名都可以使用这个证书,避免重复申请。使用OV证书的网站访问时候类似下面这样:

  2. DV(Domain Validation SSL),一个域名对应一个证书,无法使用通配符,这是最便宜的证书,申请无需人工干预,不需要组织信息,因为价格便宜,由某CA最早推出来之后,很受欢迎,但是因为没有人工审核,很多犯罪网站都使用DV。

  3. EV(Extended Validation Certificate),扩展验证证书,价格最高,审核最严,也是安全性最高的证书,能够使用一些安全性更高的加密算法,例如椭圆曲线算法,访问时还能在浏览器地址栏显示绿色,并且显示组织的名称,看起来非常高大上,如下图:

总结

目前整个互联网建立在对CA信任的基础上,要是CA作恶,那么整个互联网就会混乱了。之前就有发生过有CA误签发google证书,导致google差点被中间人攻击。

至此,整个https的加密原理和安全认证机制理论知识我们都已经讲完了,我们来回顾一下:首先客户端先校验证书,从服务端证书到二级CA再到根证书,然后双方生成一个对称加密的密钥,用证书里面的公钥加密,发送给服务端,服务端用自己的私钥解密,拿到对称加密的密钥之后,双方开始通信。

这套加密系统其实适用于所有客户端和服务端的通信,所以网景公司在1994年推出浏览器时,同时推出了ssl,应用到http就变成了https。后面咱们来看看https中,ssl协议的一些具体细节。

零门槛学习https–(4)https协议详解

零门槛学习https--(2)https中s的秘密

上一篇:零门槛学习https–(1)为什么我们要用https

非对称加密在目前的计算机领域内是非常安全的,主要还是受制于目前的计算能力,或许某天量子计算机的出现会改变这个局面。RSA的本质就是一个数学算法,所以本篇即使你不懂任何计算机知识,也能理解RSA算法的原理,但是其中会涉及到大量的数学知识。

RSA

前面已经介绍过RSA的名称由来,下面来介绍下RSA的安全本质:大整数的因数分解

举个例子:求77的因数分解,很简单,解是7和11,或许你在高中或者初中就学过这个,很诧异这能成为现代互联网安全的基础?那么你可以看看下面这个数字:

1
12301866845301177551304949
58384962720772853569595334
79219732245215172640050726
36575187452021997864693899
56474942774063845925192557
32630345373154826850791702
61221429134616704292143116
02221240479274737794080665
351419597459856902143413

这个就是人类目前破解过的最长的一个整数,在2009年才破解成功,转成二进制就是768位,而现在普遍都是2048位的加密,如果非要破解,那么所需时间是一个天文数字。如果有一天,有人发明了简单的因数分解的方式,那么RSA就很容易被破解了,目前,基本上只有暴力破解,也就是一个数一个数地测试。

RSA的思路

上面那个数等于下面这两个数的乘积,计算这两个数的乘积很简单,计算机在瞬间就可以给出答案,但是只有两个数的乘积,而让你求出其因数,就几乎是不可能了,当然这是基于大整数的情况下,简单的整数,通过暴力破解,还是可以求出来的。

1
33478071698956898786044169
84821269081770479498371376
85689124313889828837938780
02287614711652531743087737
814467999489
    ×
36746043666799590428244633
79962795263227915816434308
76426760322838157396665112
79233373417143396810270092
798736308917

我们把这两个数分别称为pq,这两个数的乘积称为n,从这个角度出发,只要加密者拥有pq,很容易算出乘积n,而尝试破解的人,只有n,就没法算出pq了。

如何生成公私钥?

本质已经知道了,那么我们来生成RSA的公钥和私钥吧,生成公钥和私钥总共分为五步:

1. 随机选择两个质数p和q

质数又称素数,具体的特性和定义请参考这里

比如这里我选择了p=17,q=23

2. 将这个两个数相乘得到n

17 * 23 = 391391换算成二进制就是110001000,这里的位数就是9位,这就是我们密钥的长度。选择RSA密钥长度的时候,其实就是选择这个n的长度,长度越大,安全性越高,当然加密和解密的时候耗费的计算量也更大。

3. 计算n的欧拉函数φ(n)

欧拉函数的作用是求得大于1小于n的所有质数的个数,例如符合φ(8)的情况是:2, 3, 5, 7,也就是φ(8)的值为:4,具体有关欧拉函数的其他特性请参考这里

我们这里φ(n)可以这么求值:

1
φ(n) = (p-1)(q-1).

这里,φ(n) = ( 17 -1 ) * ( 23 - 1 ) = 352

4. 随机选择一个整数e, 需要符合条件:1 < e < φ(n)并且e和φ(n)互质

也就是说,eφ(n)不能有公约数,并且φ(n)不能是e的倍数。

举个例子:φ(n) = 352,所以e可以选的数有3, 5, 7, 11 ....,这里我选择17

在现实场景中,通常e的选择是65537,为什么要选择这个数呢?请参看这篇文章,解释得非常清楚,总的来说,比65537大的数,在现有的硬件和软件场景下,会造成计算变慢,而比65537小的数,在安全性上会有减弱,所以65537是一个折中的选择。

5. 计算e对于φ(n)的模反元素d

求模

求模操作在大部分计算机语言中操作符都是%,比如:10 % 3 = 1,指的是余数。

同余

三横的等号,代表同余,两个整数ab,若它们除以正整数m所得的余数相等,则称 ab对于模 m同余,例如:

1
10 ≡ 1 (mod 3)

10 和 1 对于 3 同余。

模反元素

模反元素也成为模逆元

一整数a对同余n之模逆元是指满足以下公式的整数 b

也可以写成以下的式子

整数 a 对模数 n 之模逆元存在的充分必要条件是 a 和 n 互素,若此模逆元存在,在模数 n 下的除法可以用和对应模逆元的乘法来达成,此概念和实数除法的概念相同。

以上是维基百科对于模反元素的介绍,将eφ(n)代入公式就变成了:

1
e * d ≡ 1(mod φ(n))

也就是说e * d的结果除以k * φ(n)的余数是1,所以我们的公式就变成了:

1
e * d - 1 = k * φ(n);

eφ(n)代入:

1
231 * d - 1 = k * 352

转变一下位置:

1
231x - 352y = 1

就变成了一个二元一次方程,初中时候就求过二元一次方程的解,但是必须得有两个二元一次方程才能求出解,不然就是一个直线方程了,这里我们采用扩展欧几里得算法来进行求解。

欧几里得算法

我们先看看欧几里得算法的定义:欧几里得算法又称为辗转相除法,是一种求最大公约数的方法,其核心思想如下图:

假设我们要求12076的最大公约数,可以这么计算:

1
首先选择大的数减去小的数

120 - 76 = 44

现在我们剩下76 和 44两个数,继续第一步操作

76 - 44 = 32

44 - 32 = 12

32 - 12  = 20

20 - 12  = 8

12 - 8  = 4

8  - 4  = 4

4  - 4  = 0

所以,我们就可以求出,12076的最大公约数是4

扩展欧几里得算法

看名字就可以知道这是欧几里得算法的扩展,其核心思想如下:

已知a和b,求解一组x, y使得ax+by=Gcd(a, b)=d (Gcd(a, b) 表示a和b的最大公约数)

用类似辗转相除法来求解这个等式17x - 352y = 1

1
352 = 17 * 20 + 12
17  = 12 * 1 + 5
12  = 5 * 2 + 2
5   = 2 * 2 + 1

改变一下等式两边

1
12  = 352 - 17 * 20
5   = 17 - 12
2   = 12 - 5 * 2
1   = 5 - 2 * 2

把等式代入上一个等式

1
1  = 5 - 2 * 2
1  = 5 -( 12 - 5 * 2 )* 2 // 代入等式:2 = 12 - 5 * 2
1  = 5 - 12 * 2 + 5 * 4
1  = 5 * 5 - 12 * 2
1  = ( 17 - 12 ) * 5 - 12 * 2 // 代入等式:5 = 17 - 12
1  = 17 * 5 - 12 * 5 - 12 * 2
1  = 17 * 5 - 12 * 7
1  = 17 * 5 - ( 352 - 17 * 20 ) * 7 // 代入等式:12 = 352 - 17 * 20
1  = 17 * 5 - 352 * 7 + 17 * 140
1  = 17 * 145 - 352 * 7

即可得出:x = 145, y = 7

结果

在第五步中我们想要的d就是这里的x,所以,d = 145

作为一个直线方程,这里理论上这里会有无数个整数解,的确,尝试一下就发现,所有整数解都是能计算的,只是数字越大,计算量越大,但是要注意,这里的d不能小于0。

组合公钥和私钥

到这里,公钥和私钥所需要的东西都齐全了,({n, e})就是公钥,而({n, d})就是私钥,一般会使用ASN.1来表达。

加密

首先,我们用公钥加密。

要加密的数据m

m需要满足以下条件:

  1. m必须是正整数(字符串之类的可以取arcii)
  2. m必须小于n

加密公式

me ≡ c (mod n)

这里的c就是我们的密文。

上面我们计算的n是:391,e是:17, 那假设我们要加密的内容是:11,所以我们的密文就是:198

这里非常需要注意的一点就是,需要使用一些大数计算的方式,而不能使用普通的double之类的类型,因为double类型,还有js等语言的默认的数字类型尾数位只有52位,无法精确表达比2的53次更大的数字

解密公式

cd ≡ m (mod n)

c是:198,d是:145,n是:391,解出我们的明文是:11,至此,我们的整个加密和解密过程就结束了。也许你会好奇,为什么这么算就能算出相等的结果,下面就来证明一下。

公式证明

我们的加密公式是:

me ≡ c (mod n)

我们的解密公式是:

cd ≡ m (mod n)

根据上面的规则,c可以这么表达:

c = me - kn

c代入我们的解密方程:

(me - kn)d ≡ m (mod n)

因为这是一个同余等式,等号左边加减n都不会影响等式,所以我们可以把等式简化为

med ≡ m (mod n)

当我们在求d的时候有同余等式:

ed ≡ 1 (mod φ(n))

这个等式也可以写成这个样子:

ed = h * φ(n) + 1

代入刚刚简化后的等式:

mhφ(n)+1 ≡ m (mod n)

到这里,只要我们能够证明这个等式是成立的,那么就能够证明我们的加密和解密公式是成立的,这里就有两种情况了:

m和n是互质的关系

欧拉定理)如果两个正整数a和n互质,则n的欧拉函数 φ(n) 可以让下面的等式成立:

aφ(n) ≡ 1 (mod n)

我们把mn代入公式可以得到:

mφ(n) ≡ 1 (mod n)

因为mn互质,那么以下等式依然成立:

(mφ(n))h * m ≡ m (mod n)

对指数稍微换算一下就能得到我们之前的等式了,mn互质的情况下,我们很容易就能证明之前的等式成立。

m和n不是互质的关系

首先我们有n = p * q,因为mn不是互质的,而因为n是两个质数相乘的结果,也就是说p或者q就是mn的一个公约数,所以有m = p * k,或者m = q * k。假设pmn的公约数,那么就有m = p * k

然后因为pq都是质数,质数和除了是自己倍数之外的数都互质,又因为m必须小于n,所以这里k取值必然不能是q或者更大的数,所以我们有一个结论是:k必然和q互质。

k * p必然和q互质,把k * pq代入,所以我们能够得出以下同余等式:

(kp)φ(q) ≡ 1 (mod q)

因为k * pq互质,所以可以有:

(kp)h * φ(q) + 1 ≡ kp (mod q)

而我们之前已经求出:

ed = h * φ(n) + 1

代入刚刚的式子:

kped ≡ kp (mod q)

假设有t,使得求模运算可以写成:

kped = t q + k p

转换一下等式:

kped - 1 = t * q

先假设k * pt互质,也就是说k * p能够整除q,因为pq是互质关系,而上面我们也得出k必然和q互质,所以我们的假设k * pt互质不成立,上方我们得出k必然和q互质,由此可得p必然能够整除t才能使得等式成立,也就是有:t = t * p,由此可得如下等式:

kped = t pq + kp

因为m = kp,而n = pq,所以:

med = tn + m

写成同余等式可得:

med ≡ m (mod n)

这里就得出了我们刚刚求出的等式。

结论

到这里,我们已经证明了两种情况下等式都是成立了,也就是明文通过公钥加密之后,使用私钥也必然能够得到原本的结果,RSA算法也就成立了。

RSA中的对称性

其实你会发现,RSA里面,公钥加密的东西私钥能够解密,同样的,从公式中发现,私钥加密的东西公钥也能解密,这也是非常重要的一个特性。那么,为什么不能把({n, d})作为公钥给用户呢?因为({n, e})中,n是公开的,e基本都使用常数65537,所以很容易就被猜到了,因此,虽然在算法上都能加密和解密,但是只把({n, e})作为公钥,公钥和私钥有非常严格的区分。

总结

有了这么安全的加密方式,那么我们就可以开始给HTTP加密了,那么https究竟是怎么做的呢,一起来看看:

零门槛学习https–(3)https的安全策略

零门槛学习https--(1)为什么我们要用https

目前几乎主流的所有网站都使用了https,而且苹果也强制要求开发者使用https要传输数据,我们先不说什么是https,以及为什么需要https,因为任何技术的诞生都是因为现实中遇到的问题,而诞生了这个技术去解决问题,那么,https是为了解决什么问题呢?

http

http是一个非常伟大的协议,几乎承载了整个互联网,它有一个特点,那就是明文传输,如今家用的一个最简单的网络情况往往是,你连着路由器,路由器连着一个猫,然后接入电信运营商,这时候,我们就遇到了两个问题:

  1. 路由器被人动了手脚,跟女神聊天的聊天记录全被别人看到了。
  2. 随便打开一个网页,右下角都会弹出一些诡异的广告。

也许你不知道也不在乎自己的聊天记录被人看到了,那么当你兴致勃勃打开115准备欣赏大片的时候,右下角的广告一定能让你炸毛了,比如下面这样子:

因为http是明文传输,那么想查看别人的信息,也就很容易了,同样,在你返回的http页面插入一个js脚本也是轻而易举,运营商的广告就是这么来的,非常无耻。

http有多不安全?

打开Wireshark随便抓一个包看看

cookie轻松就拿到了,在一些安全性不是很高的网站,有了cookie,你就相当于在短时间内登陆了这个账号,甚至都不用账号密码。

返回的html也完整得能被解析出来,运营商插入一段广告JS还好,在一些安全性不是很高的网站插入监听键盘的脚本,然后就能拿到账号密码了,再通过撞库等方式,你在很多网站或许都不安全了。

解决办法

聪明的你肯定想到了,既然都是明文传输惹得祸,那么我加密就行了呀。的确,加密就行了,但是这么简单的一句话,里面可是包含了无数革命先烈的研究成果,造就了https的由来。

加密方法

既然提到了加密,那么无非就是三种加密方法:

  • 摘要算法。摘要算法严格意义上来说其实也不算是加密方法,最大的特点是不可逆,并且普遍防碰撞性较好。典型的有MD5,sha256等算法。现在有一些彩虹表,存储了大量的摘要信息以及其原文,并且还在不断增加,加上一些暴力破解技术,例如ophcrack等工具,几秒内即可破解windows登陆密码。

  • 对称加密。典型的一个对称加密算法就是凯撒加密,比如原文是:1234,那么约定一个密钥1,加密的时候每一位都+1,所以密文就是:2345,解密的时候很简单,只要每一位都-1即可,运算速度很快,唯一的缺点是,两个人之间的密钥有一个人的泄露了,那么所有的通信都不安全了,并且传递密钥的时候除非当面给,不然都不安全。

  • 非对称加密。最大的特点是通信双方的密钥是不一样的,并且加密者的密钥只能用于加密,无法解密,只有解密者的密钥能解密。典型的一个是RSA,几乎是奠定了现代互联网安全的基石,在HTTPS中被大量采用,其他例如椭圆曲线加密算法(ECC),以及ElGamal等算法。RSA三个字母取自三位发明者的首字母:Ron Rivest、Adi Shamir、Leonard Adleman,由这三位数学家在1977年提出。

对称加密虽然也很有多种方式,但是相对来说还是比较好理解,但是非对称加密用一个密钥加密,却能用另外一个密钥解密,这个可能就不大好理解了,下面跟大家主要聊一聊非对称加密中的RSA具体是如何实现的。

零门槛学习https–(2)https中s的秘密

一个使用Launch-Screen但是无法显示图片的坑

使用StoreBoard来作为Launch Screen的时候,通常做法是在Store Board里面加一个UIImageView,然后里面设置相应的图片就OK了,例如下面这样:

我把app-starpup这张图片放到了Assets.xcassets里面,然后在storyboard里面引用了一下,一切都很简单,看起来也毫无问题,但是编译完到启动的时候,发现无论如何这样图片都显示不出来,我以为是同时设置了Launch Image的问题,然后调试了差不多一个小时,最后终于意识到了问题所在:Assets.xcassets里面的文件在启动的时候还没有被加载,把图片放到某个文件夹里面,然后再引用文件夹里面的图片,问题就解决了。

多次setRootViewController导致view无限叠加的问题

背景

最近在开发一个iOS项目,有这么几个页面:登录页、引导页、主页。因为这几个页面之间几乎没有关联,所以就做成了3个不同的viewController,然后通过直接[UIWindow setRootViewController:]的方式来进行页面切换,其中,引导页和主页是单例,登陆页因为某些原因每次使用都会实例化。

出现的问题

正常使用流程是:引导页-> 登录页 -> 主页,流程很顺,但是在退出后就出问题了,在主页退出后,重新展示登录页,然后在登陆页登陆完了之后,调用[UIWindow setRootViewController:]设置主页单例,打了断点发现逻辑已经调用,但是发现无论怎么设置,都没用,屏幕上依然是登录页,主页并没有显示出来,非常疑惑。

问题原因

打开xcode的调试功能:View UI Hierarchy,就能看到类似如下的场景了。(保密需要没有用自己的图)

最下面是引导页,然后中间是登录页,然后最上面是主页,然后因为退出之后又显示了登陆页,而登录页不是单例,所以在主页上又覆盖了一层登录页,而因为主页是单例,所以在第二次setRootViewController之后,并没有生效。而看了一下setRootViewController的作用,主要逻辑就是把要添加的viewController的view添加到window上,UIWindow本身就是一个view。

危害

这个问题其实还是挺有风险的,如果我的主页不是单例,那么我甚至都发现不了这个问题,只会一层一层往上叠加,就会造成内存泄露了。

解决方法

知道了原因,解决起来就轻松了,两种解法:

  1. 不使用setRootViewController的方式,而且采用pushViewController或者presentViewController的之类的方式去显示页面。
  2. 修改setRootViewController,在每次调用之前先删掉UIWindow上所有的view,然后在添加。

其实正常来说,还是推荐使用第一种方式来切换页面,而我因为改动比较大,而且时间比较急,所以采用了第二种方式,代码如下:

1
- (void)setRootViewController:(UIViewController *)rootViewController
{
    //remove old rootViewController's sub views
    for (UIView* subView in self.rootViewController.view.subviews)
    {
        [subView removeFromSuperview];
    }
    
    //remove old rootViewController's view
    [self.rootViewController.view removeFromSuperview];
    
    //remove empty UILayoutContainerView(s) remaining on root window
    for (UIView *subView in self.subviews)
    {
        if (subView.subviews.count == 0)
        {
            [subView removeFromSuperview];
        }
    }
    
    //set new rootViewController
    [self addSubview:rootViewController.view];
    [super setRootViewController:rootViewController];
}