• 关于 防篡改是什么 的搜索结果

问题

有什么好的防止请求数据的篡改方案吗

景凌凯 2020-04-24 16:43:00 0 浏览量 回答数 1

回答

签名是保证数据的完整性与不篡改. 加密是保证安全不被别人查看到明文. 不是一回事.######这点我当然清楚,加签本身就是防篡改。签名本身是用到了加密的。加密方案如果放到客户端就容易泄露。如果放到服务端你调用获取签名及内容看似安全,但是你调用获取黑客也可以获取。除非你获取的url也加签,这样就是个无限循环。###### 为什么要请求服务器获取签名,签名是客户端直接就做好了然后船王服务器验证码?######回复 @小桥流水凌凌漆 : 你浏览器里面要做签名?######回复 @关河 : 秘钥在客户端,如果是app还好。如果是浏览器,一定会泄露,因为逻辑就在js里写。对所有人可见的######回复 @小桥流水凌凌漆 : 秘钥分配给你啊,秘钥不泄露不就行了######客户端比如浏览器你要做签名 要有签名工具,要有秘钥。这种东西放在客户端,很容易就泄露了。别人拿到这些东西想怎样就怎样。###### 你说的也有道理,主要就是这个secret如何安全不泄露出去,但是互联网通信几乎没有一定安全的吧,签名也只是相对安全的做法######https相对能做到信息的加密,做不到100%防篡改。只做到客户端对服务器的信任,做不到服务器对客户端信任。token本来可以做到对客户端信任,但是由于在客户端导致容易被泄露。所以密码、签名。再互联网就是个永恒的循环无解。支付表秘钥也只是把责任推给了商户,商户把秘钥丢了怪不着支付宝,不是终极解决方案。还是要保证客户端代码不透明,直接客户端做签名才行。

爱吃鱼的程序员 2020-06-05 12:37:53 0 浏览量 回答数 0

回答

各位大神有遇到过的吗,是ECshop2.73程序的漏洞,安全狗能防护住吗?wap防火墙已经安装,没用,还是网页被篡改,跳转到北京赛车投注优乐彩网。另选模版网站,要注意什么?主要是要求安全,也帮忙推荐一下。

挥霍年代 2019-12-02 01:38:11 0 浏览量 回答数 0

新用户福利专场,云服务器ECS低至96.9元/年

新用户福利专场,云服务器ECS低至96.9元/年

回答

是什么类型网站呢?如果包含会员注册、登录、交易这样的业务功能的话,强烈建议上下web应用防火墙,提前给网站做好防御。挂马有可能导致网站数据丢失和篡改,平时多关注下管理控制台,有安全提醒的时候就早做清理和防护;当然除了防御,网站自身的代码有漏洞,也可能导致被入侵。

2019-12-01 23:34:00 0 浏览量 回答数 0

问题

服务器频繁被挂马怎么办?介绍一款软件帮你解决烦恼!

梦丫头 2019-12-01 20:57:26 9507 浏览量 回答数 11

问题

#技塑料人生#  Linux下触发式文件同步的实现

qiujin2012 2019-12-01 20:56:46 13123 浏览量 回答数 5

回答

服务器常被攻击表明很可能存在安全漏洞,建议及时查找漏洞,安装补丁、升级系统,并做好服务器的日常防护。 1.设置复杂密码 不要小看密码设置,其对于保持在线安全和保护数据至关重要。创建复杂的云服务密码,字符越多,电脑就越难猜出。特殊字符、数字和字母的随机组合要比姓名或生日更强。 2.杀毒和高防应用 为服务器建立多道防线,杀毒程序通常可以在病毒感染电脑前识别并清除掉。专业的高防服务是应对攻击的最好办法,推荐西部数码的ddos高防,可有效防御各类ddos攻击。 3.保持备份和更新 保持应用程序更新到最新版。如果网站是基于WordPress的,建议把不使用的插件卸载或完全删除,而不只是禁用。在更新之前备份重要数据。另外,仔细检查文件权限,谁有何种级别的权限。 4.部署SSL证书 网站最好使用SSL证书。超过一半以上的网站已经加密了,不要落下。在网页上如需提交敏感信息,优先检查网站域名前是否是https。浏览器会在这种链接前显示一个绿色锁图标。 5.数据库避免敏感信息 存在数据库里的身份证和银行卡信息是易受攻击和盗取的目标。所以,建议不要把此类信息存储在数据库中。 服务器安全这问题,很重要,之前服务器被黑,管理员账号也被篡改,远程端口也登陆不了了。,在网上搜索了一些服务器安全设置以及防黑的文章,对着文章,我一个一个的设置起来,费了好几天的时间才设置完,原以为会防止服务器再次被黑,没想到服务器竟然瘫痪了,网站都打不开了,无奈对服务器安全也是一窍不通,损失真的很大,数据库都损坏了,我哪个后悔啊。娘个咪的。最后还是让机房把系统重装了。找了几个做网站服务器方面的朋友,咨询了关于服务器被黑的解决办法,他们建议找国内最有名的服务器安全的安全公司来给做安全维护,找了sinesafe,服务器被黑的问题,才得以解决。 一路的走来,才知道,服务器安全问题可不能小看了。经历了才知道,服务器安全了给自己带来的也是长远的利益。 希望我的经历能帮到楼主,帮助别人也是在帮助我自己。 下面是一些关于安全方面的建议! 建站一段时间后总能听得到什么什么网站被挂马,什么网站被黑。好像入侵挂马似乎是件很简单的事情。其实,入侵不简单,简单的是你的网站的必要安全措施并未做好。 一:挂马预防措施: 1、建议用户通过ftp来上传、维护网页,尽量不安装asp的上传程序。 2、定期对网站进行安全的检测,具体可以利用网上一些工具,如sinesafe网站挂马检测工具! 序,只要可以上传文件的asp都要进行身份认证! 3、asp程序管理员的用户名和密码要有一定复杂性,不能过于简单,还要注意定期更换。 4、到正规网站下载asp程序,下载后要对其数据库名称和存放路径进行修改,数据库文件名称也要有一定复杂性。 5、要尽量保持程序是最新版本。 6、不要在网页上加注后台管理程序登陆页面的链接。 7、为防止程序有未知漏洞,可以在维护后删除后台管理程序的登陆页面,下次维护时再通过ftp上传即可。 8、要时常备份数据库等重要文件。 9、日常要多维护,并注意空间中是否有来历不明的asp文件。记住:一分汗水,换一分安全! 10、一旦发现被入侵,除非自己能识别出所有木马文件,否则要删除所有文件。 11、对asp上传程序的调用一定要进行身份认证,并只允许信任的人使用上传程序。这其中包括各种新闻发布、商城及论坛程 二:挂马恢复措施: 1.修改帐号密码 不管是商业或不是,初始密码多半都是admin。因此你接到网站程序第一件事情就是“修改帐号密码”。帐号 密码就不要在使用以前你习惯的,换点特别的。尽量将字母数字及符号一起。此外密码最好超过15位。尚若你使用 SQL的话应该使用特别点的帐号密码,不要在使用什么什么admin之类,否则很容易被入侵。 2.创建一个robots.txt Robots能够有效的防范利用搜索引擎窃取信息的骇客。 3.修改后台文件 第一步:修改后台里的验证文件的名称。 第二步:修改conn.asp,防止非法下载,也可对数据库加密后在修改conn.asp。 第三步:修改ACESS数据库名称,越复杂越好,可以的话将数据所在目录的换一下。 4.限制登陆后台IP 此方法是最有效的,每位虚拟主机用户应该都有个功能。你的IP不固定的话就麻烦点每次改一下咯,安全第一嘛。 5.自定义404页面及自定义传送ASP错误信息 404能够让骇客批量查找你的后台一些重要文件及检查网页是否存在注入漏洞。 ASP错误嘛,可能会向不明来意者传送对方想要的信息。 6.慎重选择网站程序 注意一下网站程序是否本身存在漏洞,好坏你我心里该有把秤。 7.谨慎上传漏洞 据悉,上传漏洞往往是最简单也是最严重的,能够让黑客或骇客们轻松控制你的网站。 可以禁止上传或着限制上传的文件类型。不懂的话可以找专业做网站安全的sinesafe公司。 8. cookie 保护 登陆时尽量不要去访问其他站点,以防止 cookie 泄密。切记退出时要点退出在关闭所有浏览器。 9.目录权限 请管理员设置好一些重要的目录权限,防止非正常的访问。如不要给上传目录执行脚本权限及不要给非上传目录给于写入权。 10.自我测试 如今在网上黑客工具一箩筐,不防找一些来测试下你的网站是否OK。 11.例行维护 a.定期备份数据。最好每日备份一次,下载了备份文件后应该及时删除主机上的备份文件。 b.定期更改数据库的名字及管理员帐密。 c.借WEB或FTP管理,查看所有目录体积,最后修改时间以及文件数,检查是文件是否有异常,以及查看是否有异常的账号。 如果服务器系统多了好多用户,不是被攻击。而是服务器被入侵、被黑了。服务器装完系统后,立即打补丁,并关闭不必要的服务和进程。修改服务器为复杂密码,并修改服务器的远程密码;安装服务器安全狗、网站安全狗等防护软件。 来源于网络,供您参考,如若满意,请点击右侧【采纳答案】,如若还有问题,请点击【追问】 希望我的回答对您有所帮助,望采纳! ~ O(∩_∩)O~

保持可爱mmm 2019-12-02 02:24:17 0 浏览量 回答数 0

问题

点播和播放器下载需要的参数的区别

樰篱 2019-12-01 21:04:15 2751 浏览量 回答数 1

问题

入侵防御系统怎样主宰网络安全市场金牌

elinks 2019-12-01 21:15:22 9640 浏览量 回答数 0

回答

我想了下,其实应该这样。比如现在有A(私钥A、公钥A),B(私钥B、公钥B) ,A向B发送消息,用私钥A加签、用公钥B加密,发送给B,B用私钥B解密,然后用公钥A验签。这样就可以解决上述2个问题。如果单纯的使用RSA只进行加密不签名的话,我认为是不安全的。######你这样的说法也是对的,这种叫双向认证。 A拥有A私钥、B公钥;B拥有A公钥、B私钥,这种一般用在最高级别的时候,一般很少这么用。######私钥加密用于数字签名,你对内容私钥加密,表示这内容版权归你 公钥加密用于防止信息被别人看到,只有持有私钥的人才能解密,如邮件加密发送给对方######回复 @开源中国总书记 : 老哥你这个脑瓜子真的是,A用C的公钥加密发送给C,B也用C公钥加密伪装成A发送C,你的意思是如何判断A是不是真正的A吧?首先A和C直接的通信内容只有A和C知道,A在加密的内容里面定义一串只有两个人知道的内容不就好了,例如123,C解密报文以后只要看内容中是否有123就知道是不是真正的A发的内容,B即使有C的公钥,但是不知道A和C之间通信的内容。######私钥加密的话,因为公钥是公开的,别人有可能拿到,也就是说,可以解密你的报文。 公钥加密的话,确实是只有拥有私钥的人才能解密,但是不能保证请求就是指定系统的。######私钥加密公钥解密防止发送信息中途呗篡改,公钥加密私钥解密防止信息中途被截获泄露。######还是不能解决我说的上边的2个问题###### 你举的例子 1,是用于身份验证的,你说它不能用于加密通讯。 你举的例子 2,是用于加密通讯的,你说它不能用于身份验证。 这其中的逻辑就好比,筷子不能用来喝汤,吸管不能用来吃饭,所以人发明这两种工具都没有意义吗?######回复 @开源中国总书记 : 公钥加密私钥解密,你怎么模拟我的报文,每个人公钥的拥有者都会有自己的身份ID,比如https的session之类的,你既不能获取我的身份Id,也不能获取我发送的报文内容,你怎么模拟,你自己用公钥生成的报文那不叫模拟,那是你用自己的身份做的事。 私钥加密公钥解密,这种主要是用于签名,信息是公开的,谁都可以看到,但是签名的作是为了让你知道这个信自己确定是我给你的######我的意思是,如果单纯用RSA加密的话不安全。###### "1、如果是私钥加密,公钥解密的话,因为公钥是公开出来的,所以拿到公钥的人 ,是可以解密报文的,我认为这种加密方式没意义。"   你理解有误. 这种场景是用作签名的, 就是校验信息发送者身份. 只有通过特定私钥的的信息才能被公开出来的公钥解密. 这就唯一确定了信息发送者, 达到签名(不可抵赖)的目的.  "2、如果是公钥加密,私钥解密的话,因为公钥是公开出来的,所以系统是无法识别请求就是指定系统发送的,也就是别人是可以模拟你的报文,请求你的系统。"   这种场景是做信息加密用. 发送者A通过公钥加密信息, 只有持有私钥的人C才能解密. 保证了被发送的信息不会被第三方知晓. 而B通过模拟报文的攻击方式并不是修改了A的信息, 而是B"假扮"A向系统发信息. 这种情况并不是A的密文被破解, 而是B在欺骗C, 所以不属于RSA算法漏洞.  同时, 要预防这类欺骗只需利用场景1的方式, 由A使用另外一套RSA密钥对信息签名即可. 此时B即使知晓了A要发送的原文, 由于没有A的密钥 C也无法使用公钥解密出数据. 达到了既不可篡改, 又不可抵赖的目的.  ######回复 @开源中国总书记 : 即便第三者知道报文格式, 通过公钥仿制一个报文请求系统, 这种情况也不是RSA的问题. RSA还是很好的保护了通信者之间的信息. 第三方如无密钥, 无法得知通信内容. 签名只是对RSA的活用,相当于对密文的再次加密. 要解决这种欺骗问题, 还可以通过诸如约定token来实现. 因为通信内容不可被第三方获取, 故可在报文中加入身份验证信息token来实现防骗.######回复 @开源中国总书记 : 所以需要签名啊. 使用场景1 的方式签名就可以防止这种欺骗了. 一共有两套密钥. 第一套做签名, 第二套做加密. 这样无论第三者是否知道报文格式, 都无法欺骗到系统了.######我的意思是:如果我知道你的报文结构,因为公钥是公开的,我可以使用公钥加密模拟报文请求你的系统,并不是说要篡改数据###### 加密是为了加密内容,防止别人窃据你的信息 你说的2是权限控制应该做的东西###### 发送方用接收方的公钥加密,然后用自己的私钥进行签名,然后发送消息 接收方用发送方的公钥验证发送方身份,然后用自己的私钥解密######因为发送方和接收方的公钥都公开了,还是不能解决上述2个问题###### 1上面有人说了是用来证明代码/软件所有权的,比如有人做了个木马,试图伪装成微软的程序骗过杀毒软件,可是他没有微软的私钥,无法对木马程序进行签名,也就没办法伪装成微软的程序 2既然是加密的信息别人都不知道你的报文内容怎么伪造呢,就算邪恶第三方知道你的报文格式,只要你在报文里加上一个双方提前商量好的口令就可以阻止第三方伪造报文,因为第三方不可能知道口令是什么######1、签名是可以的,这个没问题 2、你说的口令,这个口令怎么保证安全?###### 1.用于签名认证 2.并不是用于身份认证的,参考HTTPS客户端发送数据###### 两个都是有意义的。 1.私钥加密,公钥解密;用于数字签名方向。私钥-公钥是一对一的关系,使用私钥加密的值,只能用对应的公钥解开,可以验证持有者身份(即私钥表示一个身份)。 2.公钥加密,私钥解密;用于数字信封方向。对方使用公钥加密的结果,只能用对应的私钥解开,可以发送给特定持有者一些私密的消息。 你说的模拟报文,进行请求;是可以进行的。 如果要验证对方身份信息,建议使用SSL的双向验证功能######签名是没问题的。如果单纯的公钥加密,私钥解密,是不能保证请求是别人模拟的。 我想了下,其实应该这样。比如现在有A(私钥A、公钥A),B(私钥B、公钥B) ,A向B发送消息,用私钥A加签、用公钥B加密,发送给B,B用私钥B解密,然后用公钥A验签。这样就可以解决上述2个问题。

爱吃鱼的程序员 2020-06-01 11:29:18 0 浏览量 回答数 0

问题

世界杯在线直播类应用如何面对DDoS攻击

虎笑 2019-12-01 22:02:52 8598 浏览量 回答数 4

问题

什么是PCDN

云栖大讲堂 2019-12-01 21:16:54 1846 浏览量 回答数 0

回答

KeepInTouch是一个遵循区块链物联网概念的'全民人身安全'平台。 根据全球网络安全市场由市场规模预测确定,自2014年的市场规模为710亿美元,到2019年将超过1550亿美元。 (Garner)曾预测全球信息安全支出自2014年达到711亿美元,而数据丢失预防领域的增长速度创新高,达18.9%. 2015-2025网络安全市场预测:Visiongain发布了关于网络、数据、终端、应用及云安全、身份管理及安全运营领先企业的预测报告。报告指出,网络安全市场将在2015年达到754亿美元(与高德纳的预测相差不大),而市场对信息安全解决方案的需求持续高增长。 MarketsandMarkets报告指出,到2019年,网络安全市场预计增长至1557.4亿美元,复合年增长率(CAGR)从2014年至2019年将增长10.3%.航空、国防及情报垂直行业将成为网络安全解决方案的最热门提供商。北美洲将成为最大市场,亚太地区及欧洲、中东和非洲地区在市场新引力方面有望增长。 全球每年在移动及网络安全方面的支出预测为110亿美元,且不断增长。 "2014年美国的移动网络流量首次超过台式电脑,手机成为上网最为便捷、成本效益最高的设备,"AVGTechnologies公司(为Windows、iOS及安卓设备提供客户安全、隐私、业绩及备份移动应用及软件全球最大的提供商之一)的首席技术官YuvalBen-Itzhak说道,"因此,我们将看到移动app成为黑客的首要目标,而App应用商店里那些未经开发者维护的应用将成为最容易受攻击的目标之一。" 传统的"网络安全"+"人身安全"势必需要结合,而区块链技术的出现,将会使得结合成本大大降低! KeepInTouch,基于区块链技术的去中心化、账目公开、不可篡改,可追踪等优势,将极大降低在社会经济活动中的信任成本,进而重构一切经济组织形态,带来金融与科技产业颠覆性的革命。但由于现实社会中实体经济产业链条长、历史悠久且利益相关者众多,高成本的人身安全防护等问题如何保证这一课题将会是一个需要极其漫长的时间去解决的过程。 KeepInTouch定义为基于物联网概念的'全民人身安全'平台,将发行KIT代币通过KIT代币的自由流通,使KIT成为一个完全遵循自由市场经济规则的网络经济体,每一个对他人的人身安全有贡献的个体,都能在其中获得收益回报(包括但不限于安保服务,KIT回报等)。 KeepInTouch用户会拥有一些基本权利,形成你我共享物联网安全的互助场景: 在KeepInTouch平台中,基于安全防护贡献的收入将分享给用户;安全互助的用户可以将自己的定位地点,安全相关内容等发布,在被浏览和确认的同时获得收入,可以通过广泛的平台传播渠道得到收益分成。 此外,用户在KeepInTouch中的个人主页、内容、社交关系、行为数据都共享于所有平台用户,任何应用或个人读取或使用这些数据,必须得到用户授权,用户可以对自己授权的数据上报物联网安全平台,以便相关政府与安保机构以及对安保有贡献的用户进行确认。 KeepInTouch能解决什么问题? "物联网"概念的网络结构,让每个对安全有贡献的个体,都能分享收益(获得一定数量的KIT),同时提升自身安全防护。 安全的贡献:分享自己的移动轨迹信息,由有需要的第三方安保系统使用,获得第三方安保系统付出的KIT.利用去中心化、不可篡改的属性,降低安保机构的安保合作成本。 并一定程度实现追踪即将'被加害人'与不法分子之间的行动轨迹。 在KeepInTouch物联网人身安全平台中,任何基于自有权益的行为都将得到支持。KeepInTouch的底层架构并开放端口,使KeepInTouch生态中的所有人都能够通过开发Dapp创建新的应用场景并从中获益。此外,任何第三方安保应用可以接入KeepInTouch-SDK,在用户授权下直接调用KeepInTouch账号、社交关系与支付系统与安保信息等,规避传统渠道的高额分成,减少确认事件与解决事件的成本。 KeepInTouch的发展方向:将可提高人与网络安全的相关信息全部公开,提升全球安保防范,降低犯罪几率。

问问小秘 2019-12-02 03:07:12 0 浏览量 回答数 0

回答

HTTPS基本原理 一、http为什么不安全。 http协议没有任何的加密以及身份验证的机制,非常容易遭遇窃听、劫持、篡改,因此会造成个人隐私泄露,恶意的流量劫持等严重的安全问题。 国外很多网站都支持了全站https,国内方面目前百度已经在年初完成了搜索的全站https,其他大型的网站也在跟进中,百度最先完成全站https的最大原因就是百度作为国内最大的流量入口,劫持也必然是首当其冲的,造成的有形的和无形的损失也就越大。关于流量劫持问题,我在另一篇文章中也有提到,基本上是互联网企业的共同难题,https也是目前公认的比较好的解决方法。但是https也会带来很多性能以及访问速度上的牺牲,很多互联网公司在做大的时候都会遇到这个问题:https成本高,速度又慢,规模小的时候在涉及到登录和交易用上就够了,做大以后遇到信息泄露和劫持,想整体换,代价又很高。 2、https如何保证安全 要解决上面的问题,就要引入加密以及身份验证的机制。 这时我们引入了非对称加密的概念,我们知道非对称加密如果是公钥加密的数据私钥才能解密,所以我只要把公钥发给你,你就可以用这个公钥来加密未来我们进行数据交换的秘钥,发给我时,即使中间的人截取了信息,也无法解密,因为私钥在我这里,只有我才能解密,我拿到你的信息后用私钥解密后拿到加密数据用的对称秘钥,通过这个对称密钥来进行后续的数据加密。除此之外,非对称加密可以很好的管理秘钥,保证每次数据加密的对称密钥都是不相同的。 但是这样似乎还不够,如果中间人在收到我的给你公钥后并没有发给你,而是自己伪造了一个公钥发给你,这是你把对称密钥用这个公钥加密发回经过中间人,他可以用私钥解密并拿到对称密钥,此时他在把此对称密钥用我的公钥加密发回给我,这样中间人就拿到了对称密钥,可以解密传输的数据了。为了解决此问题,我们引入了数字证书的概念。我首先生成公私钥,将公钥提供给相关机构(CA),CA将公钥放入数字证书并将数字证书颁布给我,此时我就不是简单的把公钥给你,而是给你一个数字证书,数字证书中加入了一些数字签名的机制,保证了数字证书一定是我给你的。 所以综合以上三点: 非对称加密算法(公钥和私钥)交换秘钥 + 数字证书验证身份(验证公钥是否是伪造的) + 利用秘钥对称加密算法加密数据 = 安全 3、https协议简介 为什么是协议简介呢。因为https涉及的东西实在太多了,尤其是一些加密算法,非常的复杂,对于这些算法面的东西就不去深入研究了,这部分仅仅是梳理一下一些关于https最基本的原理,为后面分解https的连接建立以及https优化等内容打下理论基础。 3.1 对称加密算法 对称加密是指加密和解密使用相同密钥的加密算法。它要求发送方和接收方在安全通信之前,商定一个密钥。对称算法的安全性依赖于密钥,泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密,所以密钥的保密性对通信至关重要。 对称加密又分为两种模式:流加密和分组加密。 流加密是将消息作为位流对待,并且使用数学函数分别作用在每一个位上,使用流加密时,每加密一次,相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器,它生成的位流与明文位进行异或,从而生成密文。现在常用的就是RC4,不过RC4已经不再安全,微软也建议网络尽量不要使用RC4流加密。 分组加密是将消息划分为若干位分组,这些分组随后会通过数学函数进行处理,每次一个分组。假设需要加密发生给对端的消息,并且使用的是64位的分组密码,此时如果消息长度为640位,就会被划分成10个64位的分组,每个分组都用一系列数学公式公式进行处理,最后得到10个加密文本分组。然后,将这条密文消息发送给对端。对端必须拥有相同的分组密码,以相反的顺序对10个密文分组使用前面的算法解密,最终得到明文的消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法,现在已经被证明不安全。而3DES是一个过渡的加密算法,相当于在DES基础上进行三重运算来提高安全性,但其本质上还是和DES算法一致。而AES是DES算法的替代算法,是现在最安全的对称加密算法之一。分组加密算法除了算法本身外还存在很多种不同的运算方式,比如ECB、CBC、CFB、OFB、CTR等,这些不同的模式可能只针对特定功能的环境中有效,所以要了解各种不同的模式以及每种模式的用途。这个部分后面的文章中会详细讲。 对称加密算法的优、缺点: 优点:算法公开、计算量小、加密速度快、加密效率高。 缺点:(1)交易双方都使用同样钥匙,安全性得不到保证; (2)每对用户每次使用对称加密算法时,都需要使用其他人不知道的惟一钥匙,这会使得发收信双方所拥有的钥匙数量呈几何级数增长,密钥管理成为用户的负担。 (3)能提供机密性,但是不能提供验证和不可否认性。 3.2 非对称加密算法 在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使得对称密钥的生成和使用更加安全。 密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。 常见的密钥交换算法有RSA,ECDHE,DH,DHE等算法。涉及到比较复杂的数学问题,下面就简单介绍下最经典的RSA算法。RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数也就是质数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。我觉得RSA可以算是最经典的非对称加密算法了,虽然算法本身都是数学的东西,但是作为最经典的算法,我自己也花了点时间对算法进行了研究,后面会详细介绍。 非对称加密相比对称加密更加安全,但也存在两个明显缺点: 1,CPU计算资源消耗非常大。一次完全TLS握手,密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%,如果应用层数据也使用非对称加解密,性能开销太大,无法承受。 2,非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是2048位,意味着待加密内容不能超过256个字节。 所以公钥加密(极端消耗CPU资源)目前只能用来作密钥交换或者内容签名,不适合用来做应用层传输内容的加解密。 3.3 身份认证 https协议中身份认证的部分是由数字证书来完成的,证书由公钥、证书主体、数字签名等内容组成,在客户端发起SSL请求后,服务端会将数字证书发给客户端,客户端会对证书进行验证(验证查看这张证书是否是伪造的。也就是公钥是否是伪造的),并获取用于秘钥交换的非对称密钥(获取公钥)。 数字证书有两个作用: 1,身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。 2,分发公钥。每个数字证书都包含了注册者生成的公钥(验证确保是合法的,非伪造的公钥)。在SSL握手时会通过certificate消息传输给客户端。 申请一个受信任的数字证书通常有如下流程: 1,终端实体(可以是一个终端硬件或者网站)生成公私钥和证书请求。 2,RA(证书注册及审核机构)检查实体的合法性。如果个人或者小网站,这一步不是必须的。 3,CA(证书签发机构)签发证书,发送给申请者。 4,证书更新到repository(负责数字证书及CRL内容存储和分发),终端后续从repository更新证书,查询证书状态等。 数字证书验证: 申请者拿到CA的证书并部署在网站服务器端,那浏览器发起握手接收到证书后,如何确认这个证书就是CA签发的呢。怎样避免第三方伪造这个证书。答案就是数字签名(digital signature)。数字签名是证书的防伪标签,目前使用最广泛的SHA-RSA(SHA用于哈希算法,RSA用于非对称加密算法)数字签名的制作和验证过程如下: 1,数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希,生成消息摘要,然后使用CA自己的私钥对消息摘要进行加密。 2,数字签名的校验。使用CA的公钥解密签名,然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较,如果相同就认为校验成功。 需要注意的是: 1)数字签名签发和校验使用的密钥对是CA自己的公私密钥,跟证书申请者提交的公钥没有关系。 2)数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。 3)现在大的CA都会有证书链,证书链的好处一是安全,保持根CA的私钥离线使用。第二个好处是方便部署和撤销,即如果证书出现问题,只需要撤销相应级别的证书,根证书依然安全。 4)根CA证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。 5)怎样获取根CA和多级CA的密钥对。它们是否可信。当然可信,因为这些厂商跟浏览器和操作系统都有合作,它们的公钥都默认装到了浏览器或者操作系统环境里。 3.4 数据完整性验证 数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改,SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。 MAC算法是在密钥参与下的数据摘要算法,能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的参与下,利用MAC算法计算出消息的MAC值,并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值,并与接收到的MAC值比较。如果二者相同,则报文没有改变;否则,报文在传输过程中被修改,接收者将丢弃该报文。 由于MD5在实际应用中存在冲突的可能性比较大,所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1,中国山东大学的王小云教授在2005年就宣布破解了 SHA-1完整版算法。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。MAC算法涉及到很多复杂的数学问题,这里就不多讲细节了。 专题二--【实际抓包分析】 抓包结果: fiddler: wireshark: 可以看到,百度和我们公司一样,也采用以下策略: (1)对于高版本浏览器,如果支持 https,且加解密算法在TLS1.0 以上的,都将所有 http请求重定向到 https请求 (2)对于https请求,则不变。 【以下只解读https请求】 1、TCP三次握手 可以看到,我们访问的是 http://www.baidu.com/ , 在初次建立 三次握手的时候, 用户是去 连接 8080端口的(因为公司办公网做了代理,因此,我们实际和代理机做的三次握手,公司代理机再帮我们去连接百度服务器的80端口) 2、CONNECT 建立 由于公司办公网访问非腾讯域名,会做代理,因此,在进行https访问的时候,我们的电脑需要和公司代理机做 " CONNECT " 连接(关于 " CONNECT " 连接, 可以理解为虽然后续的https请求都是公司代理机和百度服务器进行公私钥连接和对称秘钥通信,但是,有了 " CONNECT " 连接之后,可以认为我们也在直接和百度服务器进行公私钥连接和对称秘钥通信。 ) fiddler抓包结果: CONNECT之后, 后面所有的通信过程,可以看做是我们的机器和百度服务器在直接通信 3、 client hello 整个 Secure Socket Layer只包含了: TLS1.2 Record Layer内容 (1)随机数 在客户端问候中,有四个字节以Unix时间格式记录了客户端的协调世界时间(UTC)。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中,0x2516b84b就是协调世界时间。在他后面有28字节的随机数( random_C ),在后面的过程中我们会用到这个随机数。 (2)SID(Session ID) 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 (3) 密文族(Cipher Suites): RFC2246中建议了很多中组合,一般写法是"密钥交换算法-对称加密算法-哈希算法,以“TLS_RSA_WITH_AES_256_CBC_SHA”为例: (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 浏览器支持的加密算法一般会比较多,而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。(比如综合安全性以及速度、性能等因素) (4) Server_name扩展:( 一般浏览器也支持 SNI(Server Name Indication)) 当我们去访问一个站点时,一定是先通过DNS解析出站点对应的ip地址,通过ip地址来访问站点,由于很多时候一个ip地址是给很多的站点公用,因此如果没有server_name这个字段,server是无法给与客户端相应的数字证书的,Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。 还有一个很好的功能: SNI(Server Name Indication)。这个的功能比较好,为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是,在连接到服务器建立SSL连接之前先发送要访问站点的域名(Hostname),这样服务器根据这个域名返回一个合适的CA证书。目前,大多数操作系统和浏览器都已经很好地支持SNI扩展,OpenSSL 0.9.8已经内置这一功能,据说新版的nginx也支持SNI。) 4、 服务器回复(包括 Server Hello, Certificate, Certificate Status) 服务器在收到client hello后,会回复三个数据包,下面分别看一下: 1)Server Hello 1、我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 (random_S)。 2、Seesion ID,服务端对于session ID一般会有三种选择 (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) : 1)恢复的session ID:我们之前在client hello里面已经提到,如果client hello里面的session ID在服务端有缓存,服务端会尝试恢复这个session; 2)新的session ID:这里又分两种情况,第一种是client hello里面的session ID是空值,此时服务端会给客户端一个新的session ID,第二种是client hello里面的session ID此服务器并没有找到对应的缓存,此时也会回一个新的session ID给客户端; 3)NULL:服务端不希望此session被恢复,因此session ID为空。 3、我们记得在client hello里面,客户端给出了21种加密族,而在我们所提供的21个加密族中,服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”。 (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 这就意味着服务端会使用ECDHE-RSA算法进行密钥交换,通过AES_128_GCM对称加密算法来加密数据,利用SHA256哈希算法来确保数据完整性。这是百度综合了安全、性能、访问速度等多方面后选取的加密组合。 2)Certificate 在前面的https原理研究中,我们知道为了安全的将公钥发给客户端,服务端会把公钥放入数字证书中并发给客户端(数字证书可以自签发,但是一般为了保证安全会有一个专门的CA机构签发),所以这个报文就是数字证书,4097 bytes就是证书的长度。 我们打开这个证书,可以看到证书的具体信息,这个具体信息通过抓包报文的方式不是太直观,可以在浏览器上直接看。 (点击 chrome 浏览器 左上方的 绿色 锁型按钮) 3)Server Hello Done 我们抓的包是将 Server Hello Done 和 server key exchage 合并的包: 4)客户端验证证书真伪性 客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下: 证书链的可信性trusted certificate path,方法如前文所述; 证书是否吊销revocation,有两类方式离线CRL与在线OCSP,不同的客户端行为会不同; 有效期expiry date,证书是否在有效时间范围; 域名domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析; 5)秘钥交换 这个过程非常复杂,大概总结一下: (1)首先,其利用非对称加密实现身份认证和密钥协商,利用非对称加密,协商好加解密数据的 对称秘钥(外加CA认证,防止中间人窃取 对称秘钥) (2)然后,对称加密算法采用协商的密钥对数据加密,客户端和服务器利用 对称秘钥 进行通信; (3)最后,基于散列函数验证信息的完整性,确保通信数据不会被中间人恶意篡改。 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数random_C和random_S与自己计算产生的Pre-master(由客户端和服务器的 pubkey生成的一串随机数),计算得到协商对称密钥; enc_key=Fuc(random_C, random_S, Pre-Master) 6)生成 session ticket 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 后续建立新的https会话,就可以利用 session ID 或者 session Tickets , 对称秘钥可以再次使用,从而免去了 https 公私钥交换、CA认证等等过程,极大地缩短 https 会话连接时间。 7) 利用对称秘钥传输数据 【半分钟后,再次访问百度】: 有这些大的不同: 由于服务器和浏览器缓存了 Session ID 和 Session Tickets,不需要再进行 公钥证书传递,CA认证,生成 对称秘钥等过程,直接利用半分钟前的 对称秘钥 加解密数据进行会话。 1)Client Hello 2)Server Hello

玄学酱 2019-12-02 01:27:08 0 浏览量 回答数 0

问题

网页挂马及暗链检测

yundun1 2019-12-01 20:13:12 36593 浏览量 回答数 15
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播