2016年3月

文章翻译:《在WebStorm中使用Compass》

前言

译者按:小半月前贺林大哥推荐我翻译这篇文章来扩展我的博客内容,拖了很久了,先谢大哥推荐之恩。
文章是JetBrains官方博客发表在2013年12月5日的一篇普通的科普文,作者Ekaterina Prigara,是JetBrains公司的WebStorm产品营销经理。原文出处在Using Compass in WebStorm
WebStorm集成了非常多的优秀功能,虽然可能会有点笨重,但是很强大(给我惯出了懒癌导致git什么的到现在还一脸懵逼如同咸鱼)。
我在近期的开发和学习也都是在WebStorm上进行的。手里的还不是正版,有能力的话会直接入手正版的,很值。

正文

Sass 和 SCSS 在变量(variables)、组合(mixin)、选择器继承(selector inheritance)以及其他优秀特点上扩展了原生的CSS,使得CSS在现代化开发的大背景下更加友好易用。而 Compass 框架便是在基于 Sass 同时,增加了多种多样的优秀复用样式,在大多数情况下让 Sass 和 SCSS 更好用了。

Compass

通过以下几步,在你 WebStorm 的项目上搭建 Compass 环境:

首先,确认你的电脑上已经安装过了 Ruby 环境。在已经有了 Ruby 环境之后,在控制台输入命令安装 Compass:gem install compass(事实上你完全可以直接在 WebStorm 内置的 Terminal 里进行安装)。
具体的安装信息你可以参考这里:http://compass-style.org/install/
如果你想要在新的项目里使用 Compass,你可以在 WebStorm 的 Terminal 里使用这一命令:compass init。这个操作会在项目的根目录创建 SCSS 和 CSS 文件的文件夹,并且创建一个属于 Compass 的config.rb文件。

图2

现在咱们来创建一个新的.scss(或者.css)文件。

WebStorm 将会提示你添加一个新的文件监听器(File Watcher)用以自动化地把 SCSS/Sass 文件编译成为 CSS。在我们了解自己该怎么使用 Compass 以及它是如何调用不同的文件监听器的时候,我们暂且无视这个提示。

图3

范例
@import "compass"

WebStorm 此时还没有得到 Compass 的配置。软件中会出现一个为项目配置 Compass 快速修复提示,此时按下Alt+Enter就可以应用这个快速修复,或者我们也可以进入系统偏好设置(Preferences/Setting)中的 Compass 支持(Compass Support)来激活 Compass 支持。

图4

然后选中 启用 Compass 支持(Enable Compass support),并确认。

图5

现在 WebStorm 就会为你提供一个增加 Compass 文件监听的入口了。你输入和输出文件的目录(地址)可以在文件 config.rb中相对的配置出来。此时你也能够在SCSS或Sass文件被修改的时候直接得到自动编译出来的CSS文件。

图6

如果你有一个文件结构比较个人化、并且配置文件 config.rb 还不在项目的根目录的时候,这时想把 Compass 配置给此项目,你需要确认以下两点:

  • Compass 支持设置(Compass Support settings)config.rb的文件目录是正确的;同时——
  • 参数设置(Arguments)中输入的文件目录、以及在实时刷新文件的输出目录(Output path to refresh)都要指向正确的文件目录上。

举个例子,我们当前有这样的一个项目结构:

图7

然后,在 Compass 支持设置(Compass Support settings)中,config.rb的文件目录应该是:

图8

文件监听器(File Watcher)配置应该按照如下方式:

图9

如果你在已经配置过一次 Compass 之后移动了config.rb的位置并且(/或者)移动了有 SCSS/Sass 的文件夹或 CSS 文件,不要忘记在文件监听器(File Watcher)的设置里面及时更新config.rb的文件目录和 Compass 支持设置(Compass Support settings)里面的文件目录。

文章翻译:《对比PPTP-L2TP-OpenVPN-SSTP-IKEv2》(上)

译者按:这篇文章是Douglas Crawford发表在BestVPN上的文章《PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2》的大致的译文。在给我的Debian服务器搭建VPN服务的时候,看国内的很多资料抄袭泛滥、模棱两可,这个时候在网上翻到了这篇文章(然而并不能流畅阅读),所以就此翻译一下造福人类(其实就是为了方便自己理解内容和学英语啦)。
内容上可能会有谬误,希望发现的盆友能够及时指出。以下内容均为我个人对于作者原文带有个人色彩的翻译:

因为爱德华·斯诺登对于NSA近几年致力于破解与颠覆VPN加密技术相关信息的惊人披露,也因为相关技术如雨后春笋般被开发、被美国国家标准技术研究所认证、或者疑似开发出来这些日益明显的事实,我们决定在现在对这篇热门文章进行重构和更新。
首先,我们将在查看密码学所涉及的关键概念以及NSA对于加密标准的攻势怎样影响了VPN用户之前,纲要性地列出不同VPN协议之间的主要区别以及不同协议对用户的影响。
尽管我努力尝试将以下技术讨论用通俗易懂的方式写下来,却还是相当地技术化,所以你可以直接跳到文章底部查看一个精简化的内容摘要。
更新:现在作者已经为此文章撰写了两个姊妹篇,分别题为VPN encryption terms explained (AES vs RSA vs SHA etc.)A Complete Guide to IP Leaks,如果你对这个技术课堂非常感兴趣,请务必阅读这两篇文章!

PPTP

PPTP(Point-to-Point Tunneling Protocol,点对点隧道协议)是由微软为了在拨号网络方面创建VPN而成立的一个团队开发而生,因此长期以来一直都是其企业内部的VPN标准协议。它也是一个通过搭配各种认证方法(通常是MS-CHAP v2)以提供安全性的VPN协议。因为PPTP协议作为一个在几乎所有有VPN能力的平台和设备上都可以无需安装额外软件而使用的标准,它至今仍然是企业和VPN供应商们的热门选择。同时,它有着低计算开销即可实现的优势(通俗地说就是运行速度很快)。

然而,虽然现在通常只能看见PPTP使用128位的加密密钥,但它却是早在1999年,第一个被捆绑到Windows 95 OSR2操作系统的协议。在一些被曝光的安全漏洞之中,最严重的一个就是未封装MS-CHAPv2认证的可能性。利用这个漏洞,PPTP曾在2天之内被攻破,尽管微软已经修补了漏洞(通过用作PEAP保护基于MSCHAPv2/PPTP的隧道),却还是提出了“VPN用户应使用L2TP、IPsec或者SSTP作为代替”这样的问题建议

如今大家明知PPTP协议无论如何都不够安全可靠,NSA几乎是肯定能破译PPTP加密通讯标准的事也不再是鲜为人知。而或许更令人所担忧的是,甚至在一些安全专家还认为PPTP是一个安全协议的时候,NSA已经几乎是肯定能破译那些已经储存好的、已经加密过的的旧数据了(或者这个技术此时还在研究进程中)。

优势

  • 几乎所有平台都内置好了PPTP协议的VPN客户端
  • 非常易于搭建
  • 高速

弊端

  • 不够安全(弱势的MSCHAPv2依旧被广泛使用)
  • 绝对妥协于NSA

L2TP 以及 L2TP/IPsec

L2TP(Layer 2 Tunnel Protocol,第二层隧道协议)是一种协议本身不对通过的流量进行加密或实施保密措施的VPN协议。也正是因为这个原因,L2TP通常会结合IPsec加密套件(如下所述,类似于一种密码)来实现,以此提供安全性和隐私性。
L2TP/IPsec已经被内置于所有现代化操作系统以及具有VPN功能的设置,同时它也如PPTP一般,操作简单、可快速搭建(实际上它与PPTP使用的设备通常也是相同的)。然而问题也有所产生,因为L2TP协议使用了更容易被NAT防火墙阻挡的UDP端口500,所以在防火墙后面使用L2TP协议的时候,可能需要使用更先进的配置(端口转发)。(这就不同于可以使用TCP端口443来区分正常的HTTPS流量的SSL了)
IPsec加密目前还没有什么已知大型漏洞,正确实现的情况下应该仍然是安全的,但是爱德华·斯诺登却强烈暗示其标准已向NSA所妥协,同时根据约翰·吉尔摩(安全专家和电子前沿基金会的创始成员之一)在这篇文章中解释道的内容来看,标准在设计阶段的时候可能就已经被故意弱化了。
L2tp/IPsec会进行两次数据封装,这似乎会让速度慢下来。不过首先,它的加密解密行为发生在内核之中,其次LwTP/IPsec也允许多线程(OpenVPN并没有这个功能),这两点完全可以将两次数据封装造成的减速抵消掉,结果是L2TP在理论上会比OpenVPN更快。

优势

  • 除了弊端中提到的几点,通常公认其安全
  • 易于搭建
  • 适用于全部现代化平台
  • 较OpenVPN更快

弊端

  • 或许已经向NSA妥协了(但未被证实)
  • 或许被NSA故意削弱过(但未被证实)
  • 会跟限制性防火墙产生冲突

OpenVPN

OpenVPN可以说是一种崭新的开源技术,它使用了OpenSSL库和SSLv3/TLSv1协议,通过与其他的技术融为一体,来提供一个强大而可靠的VPN解决方案。它的主要优势之一是其高度可配置性,尽管它最好被运行在UDP端口之上,却也还是能运行在其他任意端口上,甚至包括TCP端口433。也正因此,通过OpenVPN的流量与使用SSL加密的标准HTTPS流量无法被区分,同时它也很难被阻塞。
OpenVPN的另外一个优点是,尽管绝大多数的VPN供应商只使用了AES或者Blowfish加密算法,但是OpenSSL库本身支持着非常多的加密算法来提供加密(比如AES,Blowfish,3DES,CAST-128,Camellia等等)。128位的Blowfish是内置于OpenVPN是默认加密算法,虽然大众普遍认为这个算法足够安全,但是它也还是有一些已经知道的缺陷所在,甚至它的创作者在2007年也被引述说:“然而因为这一点,让我非常惊讶的是现在它还在被使用之中。如果人们问到不使用它该使用什么,我还是推荐用Twofish代替掉它。”
AES是比较新的技术,目前还没有已知的缺陷,在涉及到加密话题的时候它通常被认定是“黄金标准”,这就归功于美国政府使用其保护一些“安全”数据的行为。实际上它有128位的体积,相比于只有64位的Blowfish而言,它也能在大文件(超过1GB)的处理上稍胜一筹。然而这两种密码学已经被NIST认证了,这个问题还没被广泛认可,对此我们却仍有一些问题。可以参阅下面对此相关的讨论。
OpenVPN的执行速度取决于其采用了何种加密级别。从技术上来讲的话,IPSec因为在内核执行加解密,所以它的速度会比OpenVPN更快;同时它的多线程性也是OpenVPN所没有的。
OpenVPN已经成为了一种默认的VPN链接方式,虽然它本身是无平台支持的,但是它还是被第三方软件(包括iOS端Android端)广泛地支持着。
相比于PPTP和L2TP/IPSec,它在安装上有些繁琐(不过这是个人非常非常主观的独断)。特定平台使用通用的OpenVPN软件(如Windows端使用标准开源的OpenVPN客户端),不仅必须下载和安装客户端,还要下载和安装额外的配置文件。因此也有许多VPN供应商通过提供定制化的VPN客户端来解决这个问题。
也许在从爱德华·斯诺登处获取到的信息中最重要的一点就是,在它的完全正向加密(是一种临时密钥交换,后面会讨论到)被使用后,就不会被NSA攻破或者削弱。虽然没有人确切知晓NSA的全部能力,但种种迹象和数学运算的结构都表明,如果OpenVPN配合使用了强大的加密算法和临时密钥功能,它将会是唯一值得被考虑到的真正安全的VPN协议。不过不幸的是,并不是所有的VPN供应商都会在实现OpenVPN的过程中使用到PFS完全正向加密。
优势

  • 高度可配置性
  • 非常安全(如果使用了PFS完全正向加密,甚至对NSA都是安全的)
  • 可以绕过防火墙
  • 可以使用多种加密算法
  • 开源(因此可以很容易地去检查项目中的后门情况或者其他有可能被NSA修改过的地方)

弊端

  • 需要第三方软件
  • 安装过程比较繁琐
  • 尽管在努力改善对移动端设备的支持,缺还是不及桌面端的完善程度

SSTP

SSTP(Secure Socket Tunneling Protocol,安全套接字隧道协议)是微软在Windows Vista SP1时推出的,虽然它现在可用于Linux、RouterOS和SEIL,但是它极大程度上还是一种仅限Windows平台的协议(让它支持苹果设备的可能性等同于地狱里面出现了一个雪球)。SSTP使用了SSLv3,因此它能提供与OpenVPN相类似的优势(使用TCP433端口来避免防火墙问题),同时也因为它被直接集成到了Windows里面,所以可能会更加易用和稳定。
但是不像OpenVPN,SSTP是微软拥有的个人标准。这也就意味着代码不会开源给公众监督,同时微软有着和NSA协作的历史,加上近期的有关于Windows系统可能内置了后门的炒作,无一不在影响我们队这个标准的信心。
优势

  • 非常安全(这取决于加密方式,不过通常使用AES就非常强大了)
  • 完全集成到了Windows操作系统中(Windows Vista SP1, Windows 7, Windows 8)
  • 微软官方支持
  • 可以绕过大多数防火墙

弊端

  • 只有在Windows环境才能真正工作
  • 作为微软的专有标准,不能被独立核查出后门以及其他问题

IKEv2

IKEv2(Internet Key Exchange version 2,因特网密钥交换版本2)基于IPSec隧道协议,由微软和思科联合开发,并被兼并到了Windows7及以上版本中。从技术上讲,IKEv2(以及IKE)都不完全是一种VPN协议,而是一种用于IPSec密钥交换的控制协议。尽管如此,然而它却经常作为一个真正的VPN协议,同时它也真的在这方面发挥了非常强大的便利性和实用性。
它是被黑莓设备支持的一个标准,是开源实现可兼容于Linux以及其他操作系统的自主研发的标准。通常我们会对微软开发的任何东西都持保留意见,但是既然是开源版本,便没有什么使用问题了。
被微软称之为VPN连接的IKEv2有着非常实用的自动重连特性,当用户暂时失去互联网连接(比如进出火车隧道)的时候,它会自动重新建立VPN连接。
移动用户很特殊,正因为IKEv2提供的优秀移动性和多主机制(这个机制一般只用在客户端,而不会用在互联网供应商,通过为客户端提供多于一条互联网连接,使当中其中一条连接中断时,系统可以自动切换使用另一条连接),其大量移动端用户得以受益,这也使得它的网络变化弹性很高。这些特性对于手机用户来说确实是喜大普奔,比如那些使用智能手机的用户,从家里外出活动的时候,网络要切换到移动数据、或者从一个WiFi网络切换到另一个WiFi网络热点,在这些情况下就非常受用。
不过IKEv2更加有益于黑莓用户,因为它是黑莓设备所支持的仅有的几个VPN协议之一。
IKEv2在普及程度上不像IPSec那般无处不在(毕竟IPSec支持的平台更多),但是至少在安全性、性能和稳定性这些优秀的方面和L2TP/IPSec旗鼓相当。
也正是这些优势使得即便是旧的IKE标准(IKE/IPSec)仍然能在几乎所有iOS定制的VPN应用上,为了那些使用苹果公司官方VPN API的人无需越狱来使用它(也正因为这些优势,能让VPN供应商能够很容易地把更新配置文件推送到使用VPN的用户或者应用程序上)。
优势

  • 比PPTP,SSTP和L2TP更快,它不涉及在点对点协议(Point-to-Point protocols,PPP)上的开销
  • 非常稳定 - 尤其是切换网络或者在短暂的网络连接丢失之后重新连接的时候
  • 非常安全 - 支持AES 128,AES 192,AES 256以及3DES加密算法
  • 易于安装和配置 - 至少在用户端是如此
  • 协议也支持黑莓的设备

弊端

  • 暂时还不支持很多的平台
  • 在服务器上搭建IKEv2相对来说很费劲,这也是很多问题的隐患所在
  • 我们所对它的信任仅因为它进行了开源

译者:这篇文章拖了一个多月才磨蹭完前半部分。文章的前半部分讲的是各个协议的区别和优劣,作者主观上对于安全性考虑的很多,尤其是对美国国家安全局和微软公司采取了一个怀疑的态度。
文章中,作者多次提到爱德华·斯诺登,他的故事很有意思。他是前美国中央情报局(CIA)职员,美国国家安全局(NSA)外判技术员,后来因于2013年6月在香港将美国国家安全局关于棱镜计划监听项目的秘密文档披露给了英国《卫报》和美国《华盛顿邮报》,遭到美国和英国的通缉。根据维基百科的说明,2014年8月7日,斯诺登获得俄罗斯三年的居留许可证,也就是说他应该还在俄罗斯。这个人对于技术公开这方面付出了很多,在技术上和科学公开化上做了很多,我也只能对其聊表谢意,至少在技术发展的角度,他的行为还是值得肯定的。
文章后面还有个Issues部分,有时间会补上那段的。这篇文章写的还是非常不错的。如果发现有哪些地方出现了翻译错误或者是理解错误还请及时指正,谢谢!