• 关于 服务器端aes解密 的搜索结果

问题

请教各位大神AES 在ios php 兼容的问题

落地花开啦 2019-12-01 19:56:17 1072 浏览量 回答数 1

回答

觉得 @yuanlizbyy 的方案不够靠谱。代码和密钥都在客户端,对于真想要破解的人来说,不是什么难事。LZ嫌https的握手罗嗦,大可自己实现一个,要简单得多,只需要使用一对RSA(或其他非对称加密体系)的公钥、私钥。客户端拿着公钥,服务器拿着私钥。连接流程:客户端生成一个随机的密钥K(当然K需要足够强),将它用公钥加密,然后发送给服务器服务器用私钥解密得到K二者直接使用AES(密钥为K)加密通信。优点:安全(除非入侵服务器拿到私钥、或者破解久经考验的RSA/AES算法)、快速(只有第一次来回需要RSA解密稍慢)。缺点:需要一次握手(但可以解决:握手的来回,实际上可以用密钥K来进行加密额外发送数据)。

a123456678 2019-12-02 03:12:37 0 浏览量 回答数 0

回答

使用KMS托管密钥进行加解密 KMS(Key Management Service)是阿里云提供的一款安全、易用的管理类服务。用户无需花费大量成本来保护密钥的保密性、完整性和可用性,借助密钥管理服务,用户可以安全、便捷的使用密钥,专注于开发加解密功能场景。用户可以通过KMS控制台中查看和管理KMS密钥。 除了采用AES-256加密算法外,KMS负责保管用户主密钥CMK(Customer Master Key,对数据密钥进行加密的密钥),以及生成数据加密的密钥,通过信封加密机制,进一步防止未经授权的数据访问。 SSE-KMS服务器端加密的逻辑示意图如下。 **关于CMK的生成方式有多种: ** 使用OSS默认托管的KMS密钥 您可以将Bucket默认的服务器端加密方式设置为KMS且不指定具体的CMK ID,也可以在上传Object或修改Object的meta信息时,在请求中携带X-OSS-server-side-encryption并指定其值为KMS且不指定具体的CMK ID。OSS将使用默认托管的CMK生成不同的密钥来加密不同的对象,并且在下载时自动解密。 **使用BYOK进行加密 ** 服务器端加密支持使用BYOK进行加密,您可以将Bucket默认的服务器端加密方式设置为KMS并指定具体的CMK ID,也可以在上传Object或修改Object的meta信息时,在请求中携带X-OSS-server-side-encryption,指定其值为KMS,并指定X-OSS-server-side-encryption-key-id为具体的CMK ID。OSS将使用指定的CMK生成不同的密钥来加密不同的对象,并将加密Object的CMK ID记录到对象的元数据中,因此具有解密权限的用户下载对象时会自动解密。 **使用的BYOK材料来源有两种: ** - 由阿里云提供的BYOK材料:在KMS平台创建密钥时,选择密钥材料来源为阿里云KMS。 - 使用用户自有的BYOK材料:在KMS平台创建密钥时,选择密钥材料来源为外部,并按照要求导入外部密钥材料。导入外部密钥可参考文档导入密钥材料。 使用OSS完全托管加密 数据加密密钥的生成和管理,由OSS负责,并采用高强度、多因素的安全措施进行保护。数据加密的算法采用使用行业标准的强加密算法AES-256(即256位高级加密标准)。 OSS的服务器端加密是Object的一个属性。您可以将Bucket默认的服务器端加密方式设置为AES256,也可以在上传Object或修改Object的meta信息时,在请求中携带X-OSS-server-side-encryption并指定其值为AES256,即可以实现该Object的服务器端加密存储。

剑曼红尘 2020-03-26 18:22:18 0 浏览量 回答数 0

新手开公司,教你化繁为简

开公司到底有没有那么难,传统的手续繁琐,线下跑断腿,场地搞不定等问题,通过阿里云”云上公司注册“解决你的烦恼。

回答

OSS通过服务器端加密机制,提供静态数据保护。适合于对于文件存储有高安全性或者合规性要求的应用场景。例如,深度学习样本文件的存储、在线协作类文档数据的存储。针对不同的应用场景,OSS有如下两种服务器端加密方式: 使用KMS托管密钥进行加解密(SSE-KMS) 上传文件时,可以使用指定的CMK ID或者默认KMS托管的CMK进行加解密操作。这种场景适合于大量的数据加解密。数据无需通过网络发送到KMS服务端进行加解密,这是一种低成本的加解密方式。 注意 使用KMS密钥功能时会产生少量的KMS密钥API调用费用,费用详情请参考KMS计费标准。 使用OSS完全托管加密(SSE-OSS) 基于OSS完全托管的加密方式,是Object的一种属性。OSS服务器端加密使用AES256加密每个对象,并为每个对象使用不同的密钥进行加密,作为额外的保护,它将使用定期轮转的主密钥对加密密钥本身进行加密。该方式适合于批量数据的加解密。

剑曼红尘 2020-03-26 18:18:37 0 浏览量 回答数 0

问题

物联网服务器端消息解密失败!求助

jerrystark 2019-12-01 20:21:00 649 浏览量 回答数 2

回答

OSS 提供服务端加密和客户端加密。 服务器端加密是将数据保存到数据中心的磁盘之前进行加密,并且在下载文件时自动进行解密。OSS 提供两种服务器端加密方式: 使用KMS托管密钥进行加解密(SSE-KMS) 上传文件时,可以使用指定的CMK ID或者默认KMS托管的CMK进行加解密操作。这种场景适合于大量的数据加解密。数据无需通过网络发送到KMS服务端进行加解密,这是一种低成本的加解密方式。 注意 使用KMS密钥功能时会产生少量的KMS密钥API调用费用,费用详情请参考KMS计费标准。 使用OSS完全托管加密(SSE-OSS) 基于OSS完全托管的加密方式,是Object的一种属性。OSS服务器端加密使用AES256加密每个对象,并为每个对象使用不同的密钥进行加密,作为额外的保护,它将使用定期轮转的主密钥对加密密钥本身进行加密。该方式适合于批量数据的加解密。 客户端加密:客户端加密是指将数据发送到OSS之前在用户本地进行加密,对于数据加密密钥的使用,目前支持如下两种方式: 使用KMS托管用户主密钥 当使用KMS托管用户主密钥用于客户端数据加密时,无需向OSS加密客户端提供任何加密密钥。只需要在上传对象时指定KMS用户主密钥ID(也就是CMK ID)。 使用用户自主管理密钥 使用用户自主管理密钥,需要用户自主生成并保管加密密钥。当用户本地客户端加密时,由用户自主上传加密密钥(对称加密密钥或者非对称加密密钥)至本地加密客户端。

剑曼红尘 2020-03-26 17:48:19 0 浏览量 回答数 0

回答

加密 OSS提供服务器端加密、客户端加密以及数据传输加密三种数据加密方式。 服务器端加密 OSS通过服务器端加密机制,提供静态数据保护。适合于对于文件存储有高安全性或者合规性要求的应用场景。例如,深度学习样本文件的存储、在线协作类文档数据的存储。 针对不同的应用场景,OSS有如下三种服务器端加密方式: 使用OSS默认托管的KMS密钥(SSE-KMS) 您可以将Bucket默认的服务器端加密方式设置为KMS且不指定具体的CMK ID,也可以在上传Object或修改Object的meta信息时,在请求中携带X-OSS-server-side-encryption并指定其值为KMS且不指定具体的CMK ID。OSS将使用默认托管的CMK生成不同的密钥来加密不同的对象,并且在下载时自动解密。 使用BYOK进行加密(SSE-KMS BYOK) 服务器端加密支持使用BYOK进行加密,您可以将Bucket默认的服务器端加密方式设置为KMS并指定具体的CMK ID,也可以在上传Object或修改Object的meta信息时,在请求中携带X-OSS-server-side-encryption,指定其值为KMS,并指定X-OSS-server-side-encryption-key-id为具体的CMK ID。OSS将使用指定的CMK生成不同的密钥来加密不同的对象,并将加密Object的CMK ID记录到对象的元数据中,因此具有解密权限的用户下载对象时会自动解密。 使用OSS完全托管加密(SSE-OSS) 基于OSS完全托管的加密方式,是Object的一种属性。OSS服务器端加密使用AES256加密每个对象,并为每个对象使用不同的密钥进行加密,作为额外的保护,它将使用定期轮转的主密钥对加密密钥本身进行加密。 客户端加密 客户端加密是指将数据发送到OSS之前在用户本地进行加密,对于数据加密密钥的使用,目前支持如下两种方式: 使用KMS托管用户主密钥 当使用KMS托管用户主密钥用于客户端数据加密时,无需向OSS加密客户端提供任何加密密钥。只需要在上传对象时指定KMS用户主密钥ID(也就是CMK ID)。其具体工作原理如下图所示。 使用用户自主管理密钥 使用用户自主管理密钥,需要用户自主生成并保管加密密钥。当用户本地客户端加密时,由用户自主上传加密密钥(对称加密密钥或者非对称加密密钥)至本地加密客户端。其具体加密过程如下图所示。 数据传输加密 OSS支持通过HTTP或HTTPS的方式访问,但您可以在Bucket Policy中设置仅允许通过HTTPS(TLS)来访问OSS资源。安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。

剑曼红尘 2020-03-26 17:51:44 0 浏览量 回答数 0

回答

您好,aes key填写的是否正确? ------------------------- 这些参数不能空着 ------------------------- 是的 ------------------------- 你的IP是公网IP么?加解密需要严格按照文档的说明来做 ------------------------- 数据加密密钥    :回调消息加解密参数,是AES密钥的Base64编码,用于解密回调消息内容对应的密文。本套件下相关应用产生的回调消息都使用该值来解密。当您注册套件时,钉钉服务器为了避免无效推送,将会验证回调url的有效性,对回调url推送“验证回调URL有效性事件”,收到推送后您需要做正确的处理,才能成功创建套件。详细处理步骤请查看回调接口和“验证回调URL有效性事件”。https://open-doc.dingtalk.com/doc2/detail.htm?spm=a219a.7629140.0.0.HAJ6w3&treeId=175&articleId=104945&docType=1a.验证回调URL有效性事件此事件的推送会发生在注册套件,点击下图按钮之时。注意,若未能成功验证回调URL有效性,套件将不能被创建。1dingTalkEncryptor = new DingTalkEncryptor(Env.TOKEN, Env.ENCODING_AES_KEY, Env.CREATE_SUITE_KEY);//套件在创建中,使用默认的SUITE_KEY进行加解密此时,由于套件尚未创建成功,还未生成套件的SUITE_KEY,所以在解密post数据的时候,需要使用默认的Env.CREATE_SUITE_KEY(默认值为“suite4xxxxxxxxxxxxxxx”)来解密,以java-demo代码为例(Env为Demo中配置文件),如右,服务端demo已经做了配置。同时,Demo的配置文件(Env.java)中还需要根据套件创建时填写的TOKEN 和 ENCODING_AES_KEY做相应的更改。待成功处理『验证回调URL有效性事件』事件,套件创建成功之后,就不能再使用默认的SUITE_KEY了,需要使用套件本身的SUITE_KEY,所以需要在Env.java中配置SUITE_KEY,同时将新创建套件中的SUITE_SECRET配置到Env.java中,然后重新部署代码,此时将用下面的语句进行加解密。因为推送ticket是二十分钟推送一次,再次部署也需要等待二十分钟服务端才会推送,后续会优化该逻辑,保证即时推送,提高推送效率。dingTalkEncryptor = new DingTalkEncryptor(Env.TOKEN, Env.ENCODING_AES_KEY, Env.SUITE_KEY);//套件创建成功后,使用套件本身的SUITE_KEY进行加解密

赵挺1 2019-12-02 01:46:48 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

问题

为什么在Java中加密的RSA字节是变量?

montos 2020-03-27 22:26:21 1 浏览量 回答数 1

问题

如何实现通过客户端加密保护数据?

青衫无名 2019-12-01 21:39:10 1210 浏览量 回答数 0

回答

主要看你的用途了,B/S项目加密也没有用。密文用户是看不到的,并且你的加密算法也是明文的。如果仅仅是不想在url中显示这些信息,可以采用post方式进行提交。或者考虑SSO方案。######我现在只是想要验证这种方式的可行性,SSO在后面可能会考, 我只是用这种方式做一个简单,认证->下载服务器,只是不想用HTTPS, 且提交参数不是的明文的,两端的加解密方式只有开发者知道. 客服务端的加密是通过SDK包装发出去.######请大家指导一下方向与思路.######我发现在这个思路有问题, 加密HTTPS是少不了的. ######如果是向服器单向传送是可以的。但应该用rsa非对称加密。如果是双向的,还不如用https 简单。###### 引用来自“lirenqing2000”的评论主要看你的用途了,B/S项目加密也没有用。密文用户是看不到的,并且你的加密算法也是明文的。如果仅仅是不想在url中显示这些信息,可以采用post方式进行提交。或者考虑SSO方案。 这个方案在一些支付网站和开放平台就是这样做的,使用了动态密码、token等技术。可以研究下淘宝、拍拍、支付宝或者paypal等API,这些对你会有帮助。加密和解密模块可以在提交请求和接收请求数据的时候处理。以前采用Rest方式,在项目中使用过。可以采用AES、DES等对称加密算法。增加加密和解密模块对性能有一些影响,这个需要考虑。

kun坤 2020-06-14 09:57:50 0 浏览量 回答数 0

问题

“服务端开发文档-注册事件回调接口”让人困惑

new佳佳 2019-12-01 21:46:03 8569 浏览量 回答数 9

回答

没有服务器就先购买,系统推荐CentOS 6或7均可。 服务器购买推荐:搬瓦工VPS 配置服务端脚本需一定技术基础,技术小白推荐使用 CloudLink加速器(亚洲稳定高速线路,可免费试用10~60分钟!低至29.9元/月不限流量不限带宽!无需购买VPS自建,无技术门槛!) 本脚本适用环境: 系统支持:CentOS,Debian,Ubuntu 内存要求:≥128M 作者:秋水逸冰 关于本脚本: 一键安装 ShadowsocksR 服务端 请下载与之配套的客户端程序来连接 配置说明: 服务器端口:自己设定(如不设定,默认为 8989) 密码:自己设定(如不设定,默认为 teddysun.com) 加密方式:自己设定(如不设定,默认为 aes-256-cfb) 协议(Protocol):自己设定(如不设定,默认为 origin) 混淆(obfs):自己设定(如不设定,默认为 plain) 配置方法: 使用root用户登录,执行以下命令: wget --no-check-certificate https://raw.githubusercontent.com/teddysun/shadowsocks_install/master/shadowsocksR.sh chmod +x shadowsocksR.sh ./shadowsocksR.sh 2>&1 | tee shadowsocksR.log CentOS 7系统如出现-bash: wget: command not found错误请先执行以下命令安装wget yum -y install wget 安装完成后,脚本提示如下: Congratulations, ShadowsocksR server install completed! Your Server IP :your_server_ip Your Server Port :your_server_port Your Password :your_password Your Protocol :your_protocol Your obfs :your_obfs Your Encryption Method:your_encryption_method Welcome to visit:https://shadowsocks.be/9.html Enjoy it! 卸载方法: 使用 root 用户登录,运行以下命令: ./shadowsocksR.sh uninstall 安装完成后即已后台启动 ShadowsocksR 运行: /etc/init.d/shadowsocks status 可以查看 ShadowsocksR 进程是否已经启动 本脚本安装完成后,已将 ShadowsocksR 自动加入开机自启动。 使用命令: 启动:/etc/init.d/shadowsocks start 停止:/etc/init.d/shadowsocks stop 重启:/etc/init.d/shadowsocks restart 状态:/etc/init.d/shadowsocks status 配置文件路径:/etc/shadowsocks.json 日志文件路径:/var/log/shadowsocks.log 代码安装目录:/usr/local/shadowsocks 多用户配置示例: { "server":"0.0.0.0", "server_ipv6": "[::]", "local_address":"127.0.0.1", "local_port":1080, "port_password":{ "8989":"password1", "8990":"password2", "8991":"password3" }, "timeout":300, "method":"aes-256-cfb", "protocol": "origin", "protocol_param": "", "obfs": "plain", "obfs_param": "", "redirect": "", "dns_ipv6": false, "fast_open": false, "workers": 1 } 配置完成后,继续配置本地客户端:http://www.wangchao.info/1316.html SSR协议和混淆插件说明: 工作原理 C->S方向 浏览器请求(socks5协议) -> ssr客户端 -> 协议插件(转为指定协议) -> 加密 -> 混淆插件(转为表面上看起来像http/tls) -> ssr服务端 -> 混淆插件(分离出加密数据) -> 解密 -> 协议插件(转为原协议) -> 转发目标服务器 其中,协议插件主要用于增加数据完整性校验,增强安全性,包长度混淆等,协议插件主要用于伪装为其它协议 客户端 客户端的协议插件暂无配置参数,混淆插件有配置参数,混淆插件列表如下: plain:不混淆,无参数 http_simple:简易伪装为http get请求,参数为要伪装的域名,如cloudfront.com。仅在C#版客户端上支持用逗号分隔多个域名如a.com,b.net,c.org,连接时会随机使用其中之一。不填写参数时,会使用此节点配置的服务器地址作为参数。 http_post:与http_simple绝大部分相同,区别是使用POST方式发送数据,符合http规范,欺骗性更好,但只有POST请求这种行为容易被统计分析出异常。参数配置与http_simple一样 tls1.2_ticket_auth:伪装为tls请求。参数配置与http_simple一样 其它插件不推荐使用,在这里忽略 客户端的协议插件,仅建议使用origin,verify_sha1,auth_sha1_v2,auth_sha1_v4,auth_aes128_md5,auth_aes128_sha1,解释如下: origin:原版协议,为了兼容 verify_sha1:原版OTA协议,为了兼容 auth_sha1_v2:中等安全性,无时间校对的要求,适合路由器或树莓派,混淆强度大 auth_sha1_v4:较高安全性,有宽松的时间校对要求,混淆强度大 auth_aes128_md5或auth_aes128_sha1:最高安全性,有宽松的时间校对要求,计算量相对高一些,混淆强度较大 如不考虑兼容,可无视前两个 服务端 大部分插件都可以通过添加_compatible后缀以表示兼容原版,例如默认的http_simple_compatible或auth_sha1_v4_compatible这样; 服务端的协议插件,仅auth_*系列有协议参数,其值为整数。表示允许的同时在线客户端数量,建议最小值为2。默认值64; 服务端的混淆插件,http_simple或http_post有混淆参数,用逗号分开若干个host,表示客户端仅能使用以上任一个host连接,而留空表示客户端可以使用任意host。tls1.2_ticket_auth有混淆参数,其值为整数,表示与客户端之间允许的UTC时间差,单位为秒,为0或不填写(默认)表示无视时间差。 总结 如不考虑原版的情况下,推荐使用的协议,只有auth_sha1_v4和auth_aes128_md5和auth_aes128_sha1,推荐使用的混淆只有plain,http_simple,http_post,tls1.2_ticket_auth不要奇怪为什么推荐plain,因为混淆不总是有效果,要看各地区的策略的,有时候不混淆让其看起来像随机数据更好。

南霸天霸南北 2020-03-02 13:54:18 0 浏览量 回答数 0

问题

钉钉开放平台“常见问题常见问题常见问题“重要请关注

竹梅 2019-12-01 21:57:52 74299 浏览量 回答数 28

问题

ISV接入钉钉详细示例以及代码(JAVA版本)  --服务窗代码部分放出

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