桃夭(TAO YAO) peach blossom

桃夭(TAOYAO) peach blossom 桃之夭夭,灼灼其华。之子于归,宜其室家。 tao zhi yaoyao, zhuozhuo qi hua. zhizi yugui, yi qi qhijia. 桃之夭夭,有蕡其实。之子于归,宜其家室。 tao zhi yaoyao, youfen2 qi shi. zhizi yugui, yi qi jiashi. 桃之夭夭,其叶蓁蓁。之子于归,宜其家人。 tao zhi yaoyao, qiye zhen1zhen. zhizi yugui, yi qi jiaren.   [注释 Comment] 夭夭(yao yao): 桃花怒放的样子, blooming aspect of the peach blossom 灼灼(zhuozhuo): 花开得很茂盛,broomy  flower 华(hua):花 ,same… Continue reading 桃夭(TAO YAO) peach blossom

防范 DDoS 攻击的 15 个方法

为了对抗 DDoS(分布式拒绝服务)攻击,你需要对攻击时发生了什么有一个清楚的理解. 简单来讲,DDoS 攻击可以通过利用服务器上的漏洞,或者消耗服务器上的资源(例如 内存、硬盘等等)来达到目的。DDoS 攻击主要要两大类: 带宽耗尽攻击和资源耗尽攻击. 为了有效遏制这两种类型的攻击,你可以按照下面列出的步骤来做: 1. 如果只有几台计算机是攻击的来源,并且你已经确定了这些来源的 IP 地址, 你就在防火墙服务器上放置一份 ACL(访问控制列表) 来阻断这些来自这些 IP 的访问。如果可能的话 将 web 服务器的 IP 地址变更一段时间,但是如果攻击者通过查询你的 DNS 服务器解析到你新设定的 IP,那这一措施及不再有效了。 2. 如果你确定攻击来自一个特定的国家,可以考虑将来自那个国家的 IP 阻断,至少要阻断一段时间. 3、监控进入的网络流量。通过这种方式可以知道谁在访问你的网络,可以监控到异常的访问者,可以在事后分析日志和来源IP。在进行大规模的攻击之前,攻击者可能会使用少量的攻击来测试你网络的健壮性。 4、对付带宽消耗型的攻击来说,最有效(也很昂贵)的解决方案是购买更多的带宽。 5、也可以使用高性能的负载均衡软件,使用多台服务器,并部署在不同的数据中心。 6、对web和其他资源使用负载均衡的同时,也使用相同的策略来保护DNS。 7、优化资源使用提高 web server 的负载能力。例如,使用 apache 可以安装 apachebooster 插件,该插件与 varnish 和 nginx 集成,可以应对突增的流量和内存占用。 8、使用高可扩展性的 DNS 设备来保护针对 DNS 的 DDOS 攻击。可以考虑购买 Cloudfair 的商业解决方案,它可以提供针对 DNS 或 TCP/IP3… Continue reading 防范 DDoS 攻击的 15 个方法

大型网站的 HTTPS 实践(4):协议层以外的实践

1 前言 网上介绍 https 的文章并不多,更鲜有分享在大型互联网站点部署 https 的实践经验,我们在考虑部署 https 时也有重重的疑惑。 本文为大家介绍百度 HTTPS 的实践和一些权衡, 希望以此抛砖引玉。 2 协议层以外的实践工作 2.1 全站覆盖 https 的理由 很多刚接触 https 的会思考,我是不是只要站点的主域名换了 https 就可以?答案是不行。 https 的目的就是保证传输过程的安全,如果只有主域名上了 https,但是主域名加载的资源,比如 js,css,图片没有上 https,会怎么样? 从效果上来说,没有达到保证网站传输过程安全的目的,因为你的 js,css,图片仍然有被劫持的可能性,如果这些内容被篡改 / 嗅探了,那么 https 的意义就失去了。 浏览器在设计上早就考虑的这样的情况,会有相应的提示。具体的实现依赖浏览器,例如地址栏锁形标记从绿色变为黄色, 阻止这次请求,或者直接弹出非常影响用户体验的提示 (主要是 IE),用户会感觉厌烦,疑惑和担忧安全性。 很多用户看见这个链接会习惯性的点”是”,这样非 https 的资源就被禁止加载了。非 ie 的浏览器很多也会阻止加载一些危害程度较高的非 https 资源(例如 js)。我们发现移动端浏览器的限制目前会略松一些。 所以这里要是没做好,很多情况连网站的基本功能都没法正常使用。 2.2 站点的区别 很多人刚接触 https 的时候,觉得不就是部署证书,让 webserver 支持… Continue reading 大型网站的 HTTPS 实践(4):协议层以外的实践

大型网站的 HTTPS 实践(3):基于协议和配置的优化

1 前言 上文讲到 HTTPS 对用户访问速度的影响。 本文就为大家介绍 HTTPS 在访问速度,计算性能,安全等方面基于协议和配置的优化。 2 HTTPS 访问速度优化 2.1 Tcp fast open HTTPS 和 HTTP 使用 TCP 协议进行传输,也就意味着必须通过三次握手建立 TCP 连接,但一个 RTT 的时间内只传输一个 syn 包是不是太浪费?能不能在 syn 包发出的同时捎上应用层的数据?其实是可以的,这也是 tcp fast open 的思路,简称 TFO。具体原理可以参考 rfc7413。 遗憾的是 TFO 需要高版本内核的支持,linux 从 3.7 以后支持 TFO,但是目前的 windows 系统还不支持 TFO,所以只能在公司内部服务器之间发挥作用。 2.2 HSTS 前面提到过将用户 HTTP 请求 302 跳转到 HTTPS,这会有两个影响: 1,    不安全,302… Continue reading 大型网站的 HTTPS 实践(3):基于协议和配置的优化

大型网站的 HTTPS 实践(2):HTTPS 对性能的影响

1 前言 HTTPS 在保护用户隐私,防止流量劫持方面发挥着非常关键的作用,但与此同时,HTTPS 也会降低用户访问速度,增加网站服务器的计算资源消耗。 本文主要介绍 https 对用户体验的影响。 2 HTTPS 对访问速度的影响 在介绍速度优化策略之前,先来看下 HTTPS 对速度有什么影响。影响主要来自两方面: 协议交互所增加的网络 RTT(round trip time)。 加解密相关的计算耗时。 下面分别介绍一下。 2.1 网络耗时增加 由于 HTTP 和 HTTPS 都需要 DNS 解析,并且大部分情况下使用了 DNS 缓存,为了突出对比效果,忽略主域名的 DNS 解析时间。 用户使用 HTTP 协议访问http://www.baidu.com(或者 www.baidu.com) 时会有如下网络上的交互耗时: 图 1 HTTP 首个请求的网络耗时 可见,用户只需要完成 TCP 三次握手建立 TCP 连接就能够直接发送 HTTP 请求获取应用层数据,此外在整个访问过程中也没有需要消耗计算资源的地方。 接下来看 HTTPS 的访问过程,相比 HTTP 要复杂很多,在部分场景下,使用 HTTPS… Continue reading 大型网站的 HTTPS 实践(2):HTTPS 对性能的影响

大型网站的 HTTPS 实践(1):HTTPS 协议和原理

1 前言 百度已经于近日上线了全站 HTTPS 的安全搜索,默认会将 HTTP 请求跳转成 HTTPS。本文重点介绍 HTTPS 协议, 并简单介绍部署全站 HTTPS 的意义。 2 HTTPS 协议概述 HTTPS 可以认为是 HTTP + TLS。HTTP 协议大家耳熟能详了,目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的。 TLS 是传输层加密协议,它的前身是 SSL 协议,最早由 netscape 公司于 1995 年发布,1999 年经过 IETF 讨论和规范后,改名为 TLS。如果没有特别说明,SSL 和 TLS 说的都是同一个协议。 HTTP 和 TLS 在协议层的位置以及 TLS 协议的组成如下图: 图 1 TLS 协议格式 TLS 协议主要有五部分:应用数据层协议,握手协议,报警协议,加密消息确认协议,心跳协议。 TLS 协议本身又是由… Continue reading 大型网站的 HTTPS 实践(1):HTTPS 协议和原理

百度全站 https FAQ:技术宅告诉你如何搜索更安全

你注意到了吗?百度已经全站实现 https 了!  百度从 14 年开始对外开放了 https 的访问,并于 3 月初正式对全网用户进行了 https 跳转。 你也许会问,切换就切换呗,和我有啥关系?我平常用百度还不是照常顺顺当当的,没感觉到什么切换。 话说,平常我们呼吸空气也顺顺溜溜的,没有什么感觉,但要是没有了空气,那就没法愉快的生活了。https 对于互联网安全的重要性,正如空气对于我们人类的重要性一样。百度全站切换到 https 之后,我们才可以愉快的搜索,愉快的上网。 https 究竟是如何实现让我们更加安全呢,让百度技术宅来个深度揭秘: 问题 1:https 是什么?我有没有用到 https? https 是 http over ssl(Secure Socket Layer),简单讲就是 http 的安全版本,在 http 的基础上通过传输加密和身份认证保证了传输过程中的安全性。你通常访问的网站大部分都是 http 的,最简单的方法可以看看网址是以 http:// 开头还是https:// 开头。 以下几个截图就是 chrome,firefox,IE10 在使用 https 时的效果。 注意图中绿色的部分, 我们后面详细说说。 想进一步了解 HTTPS,可以阅读《大型网站的 HTTPS 实践(一)– HTTPS 协议和原理》 问题 2:https 为什么比… Continue reading 百度全站 https FAQ:技术宅告诉你如何搜索更安全

隐私泄露杀手锏:Flash 权限反射

前言 一直以为该风险早已被重视,但最近无意中发现,仍有不少网站存在该缺陷,其中不乏一些常用的邮箱、社交网站,于是有必要再探讨一遍。 事实上,这本不是什么漏洞,是 Flash 与生俱来的一个正常功能。但由于一些 Web 开发人员了解不够深入,忽视了该特性,从而埋下安全隐患。 原理 这一切还得从经典的授权操作说起: Security.allowDomain('*') 对于这行代码,或许都不陌生。尽管知道使用 * 是有一定风险的,但想想自己的 Flash 里并没有什么高危操作,把我拿去又能怎样? 显然,这还停留在 XSS 的思维上。Flash 和 JS 通信确实存在 XSS 漏洞,但要找到一个能利用的 swf 文件并不容易:既要读取环境参数,又要回调给 JS,还得确保自动运行。 因此,一些开发人员以为只要不与 JS 通信,就高枕无忧了。同时为了图方便,直接给 swf 授权了 *,省去一大堆信任列表。 事实上,Flash 被网页嵌套仅仅是其中一种而已,更普遍的,则是 swf 之间的嵌套。然而无论何种方式,都是通过 Security.allowDomain 进行授权的 —— 这意味着,一个 * 不仅允许被第三方网页调用,同时还包括了其他任意 swf! 被网页嵌套,或许难以找到利用价值。但被自己的同类嵌套,可用之处就大幅增加了。因为它们都是 Flash,位于同一个运行时里,相互之间存在着密切的关联。 我们如何将这种关联,进行充分利用呢? 利用 关联容器 在 Flash 里,舞台(stage)是这个世界的根基。无论加载多少个 swf,舞台始终只有一个。任何元素(DisplayObject)必须添加到舞台、或其子容器下,才能展示和交互。 因此,不同 swf 创建的元素,都是通过同一个舞台展示的。它们能感知相互的存在,只是受到同源策略的限制,未必能相互操作。 然而,一旦某个… Continue reading 隐私泄露杀手锏:Flash 权限反射

隐私泄露杀手锏 —— Flash 权限反射

前言 一直以为该风险早已被重视,但最近无意中发现,仍有不少网站存在该缺陷,其中不乏一些常用的邮箱、社交网站,于是有必要再探讨一遍。 事实上,这本不是什么漏洞,是 Flash 与生俱来的一个正常功能。但由于一些 Web 开发人员了解不够深入,忽视了该特性,从而埋下安全隐患。 原理 这一切还得从经典的授权操作说起: Security.allowDomain('*') 对于这行代码,或许都不陌生。尽管知道使用 * 是有一定风险的,但想想自己的 Flash 里并没有什么高危操作,把我拿去又能怎样? 显然,这还停留在 XSS 的思维上。Flash 和 JS 通信确实存在 XSS 漏洞,但要找到一个能利用的 swf 文件并不容易:既要读取环境参数,又要回调给 JS,还得确保自动运行。 因此,一些开发人员以为只要不与 JS 通信,就高枕无忧了。同时为了图方便,直接给 swf 授权了 *,省去一大堆信任列表。 事实上,Flash 被网页嵌套仅仅是其中一种而已,更普遍的,则是 swf 之间的嵌套。然而无论何种方式,都是通过 Security.allowDomain 进行授权的 —— 这意味着,一个 * 不仅允许被第三方网页调用,同时还包括了其他任意 swf! 被网页嵌套,或许难以找到利用价值。但被自己的同类嵌套,可用之处就大幅增加了。因为它们都是 Flash,位于同一个运行时里,相互之间存在着密切的关联。 我们如何将这种关联,进行充分利用呢? 利用 关联容器 在 Flash 里,舞台(stage)是这个世界的根基。无论加载多少个 swf,舞台始终只有一个。任何元素(DisplayObject)必须添加到舞台、或其子容器下,才能展示和交互。 因此,不同 swf 创建的元素,都是通过同一个舞台展示的。它们能感知相互的存在,只是受到同源策略的限制,未必能相互操作。 然而,一旦某个… Continue reading 隐私泄露杀手锏 —— Flash 权限反射