网页设计心得体会正文,合肥网站推广优化公司,wordpress上传到云,网络技术服务公司文章目录 前提知识原理第一次对话第二次对话第三次对话 总结发现 前提知识
KDC#xff1a;由AS、TGS#xff0c;还有一个Kerberos Database组成。 Kerberos Database用来存储用户的密码或者其他所有信息#xff0c;请求的时候需要到数据库中查找。 AS#xff1a;为客户端提… 文章目录 前提知识原理第一次对话第二次对话第三次对话 总结发现 前提知识
KDC由AS、TGS还有一个Kerberos Database组成。 Kerberos Database用来存储用户的密码或者其他所有信息请求的时候需要到数据库中查找。 AS为客户端提供TGT票据同时进行信息验证。 TGTTicket Granting Tickets一个信息票据可以看做是一种入场票 TGS(Ticket Granting Server) : 一个服务器验证 TGT 与 Authenticator(密码证明信息)为客户端提供 Service Tickets(票证服务)。Kerberos Database是一个数据库当我们请求的时候会发送自己的用户ID/NAME会来到数据库中查找是否存在… Session表示会话在kerberos中KDC会随机生成两种重要的会话钥匙
TGS Session Key请求的服务 Server Session Key
原理 第一次对话 Client 发送信息包到AS中明文发送
自身的 ID/NAME用户名自身 IP地址当前时间戳 上述信息发过去的时候全是明文即我们发出去之前不进行信息加密 AS 收到后首先去到数据库中查看是否有改用户名存在才继续响应答复以下信息两种在这个时候KDC随机生成了一个TGS Session Key一并发送过去
第一份信息包用客户端密钥加密发送 当前时间戳客户端即将访问的 TGS 服务器的 NAMETGS 的有效时间一般是八小时TGS Session Key 上述↑↑↑第一份信息包使用客户端对应的密钥进行加密然后传输 非明文传输同时KDC拥有密码表使用密码表与客户端进行身份认证 第二份信息包(TGT票据)这一份就是 TGT用TGS密钥加密发送 客户端 NAME客户端 IP当前时间戳客户端即将访问的 TGS 服务器的 NAMETGT 的有效时间一般是八小时TGS Session Key 上述↑↑↑第二份信息包使用TGS的个人密钥进行加密后传输 这一份发过去后客户端无法解密因为他不拥有TGS的密钥所以这也说明了为什么后面客户端需要原封不断的将TGT发回来再次验证 第二次对话
客户端收到了来自KDC发来的信息 首先客户端能够解密的信息包就只有第一份因为是用客户端自己的密钥加密发过来的所以解开后就能够获得里面的信息其实主要是要获得TGS Session Key客户端在第二次对话中需要通过该Key进行加密发送过去信息包 Client发送在本次发送的信息有三种
第一份信息包明文发送 发送客户端要访问的Service服务NAME/ID 第二份信息包用我们解出来拿到的TGS Session Key 密钥加密发送 客户端 NAME客户端 IP当前时间戳 第三份信息包TGT原本就加密了 原封不动的发送TGT票据回去 KDC收到信息包后首先使用自身密钥对TGT进行解密他需要拿到里面的TGS Session Key拿出来后将客户端的第二份信息包进行解密拿到里面的客户端信息与当前收到的第一份信息包里面的客户端信息是否一致。 其中时间戳不是比较而是通过客户端发送过来的时间与我生成TGT时间相差是否超过可容忍的时间段超过了就表示可能存在别修改的风险就会考虑是否废弃掉本次对话以及废弃票据有内鬼终止交易
只有当所有信息都没有问题的时候才进行回应下一步操作 在这个时候KDC又随机生成了一个客户端请求的服务 Server Session Key
第一份信息包使用TGS Session Key密钥加密发送 当前时间戳ticket ST票据的有效时间请求的服务 Server Session Key 第二份信息包ST票据使用请求的服务 Server自身的密钥加密发送 客户端 NAME客户端 IP服务器的IP地址认证服务器ticket ST票据的有效时间请求的服务 Server Session Key 重点是这一份数据要发过去
第三次对话
这时候客户端收到了TGS发来的最后一条数据客户端使用之前缓存的TGS Session Key 对第一份信息包进行解密最重要的是解密后拿到里面的请求的服务 Server Session Key密码但是第二份信息包无法解密是因为这是我们请求的Server的密钥加密的我们无法得知。
这时候我们检查时间戳是否超时无误就开始想最终Server发起最后的请求
第一份信息包使用请求的服务 Server Session Key密钥加密发送 客户端 NAME客户端 IP当前时间戳ticket ST票据有效时间 第二份信息包ST票据 原封不动的发送我们无法解密的ST票据信息包 Server 收到客户端发来的信息包后首先只能解密的只有用自己Server密钥对第二份信息包进行解密主要是为了拿出ST票据里面的请求的服务Server Session Key核对时间戳没有超时后取出这一份密钥就可以解密第一份信息包取出里面的客户端信息然后再与我们解出来的ST票据里面的信息与之比较是否一致
信息核对没问题后开始确定身份了服务端发送确认通信消息
第一份信息包使用请求的服务 Server Session Key密钥加密发送 请求的服务 NAME/ID当前时间戳 客户端接收到信息包后使用缓存下来的请求的服务 Server Session Key进行解密解密出来必须要包含请求的服务 NAME/ID 和 时间戳通过检查时间戳没有超市和正确的服务就表示认证成功了。然后再有效时间内都是使用Server Session Key进行双方的通讯。
总结发现 首先在其中生成的Session都是作下一次通话是否正确为目的也就是为了保证认证过程双方身份都是正确的除了客户端不知道KDC的密钥之外我们在本地使用密钥加密发送过去KDC是知道如何解密的利用这个特性KDC就可以使用他自己内部的密钥进行信息加密作为票据我们无法解密但是我们发过去响应的时候总是带有时间戳或者客户端信息我们票据中也带有这些信息然而这些信息都是KDC才能解密 所以票据就代表了对方发过来的信息是否有误可以知道是否疑似超时被截获信息了。在客户端主要是通过自身密钥获取会话的Session密钥通过Session密钥就可以解密信息包了解到是否在传输过程中信息包被修改或者发过来的信息包根本就不是KDC发来的。即使我们没有发现那么黑客也也不会解密到我们的Session对话即使解密了我们的Session密钥时间也会超时我们客户端很容易察觉该信息包不安全了。由于所有的信息传输都没有在传输我们双方各自的密钥所以黑客没有机会获取到我们的密钥只要暴力破解但是由于暴力破解需要时间即使破解出来我们时间戳超时了也会将其丢弃信息包。每一次的对话都是为下一次对话做准备比如第二次KDC使用客户端请求的服务的那一个服务器的密钥进行加密发过去给客户端即ST票据客户端是无法解密的需要他自己封装一份信息包然后把ST也一起发过去给最后的ServerServer端用自己的密钥解密第二份信息包然后与第一份客户端自己封装加密的信息包信息进行对比确认无误就认证成功。很容易发现这个过程中每一次对话都会使用不同的密钥进行加密并且产生会话密钥同时含有时间戳即使密钥被暴力破解了也会超过对应的忍受时间即会话时间结束额。kerberos认证系统总体还是很安全的主要是要选择信任的KDC如果我们的KDC被攻陷了那就没办法了裤衩都被骗走了。
