目前多数邮局服务提供商，就安全性保障来讲，仅仅局限于HTTPS登录，对于登录成功之后，用户的所有请求，均采用普通的HTTP模式。三五邮局从 用户的安全性考虑，对邮局产品进行了重大升级，提供用户从登录服务开始，直至访问服务结束，全程采用SSL保护模式功能
目前多数邮局服务提供商，就安全性保障来讲，仅仅局限于HTTPS登录，对于登录成功之后，用户的所有请求，均采用普通的HTTP模式。三五邮局从 用户的安全性考虑，对邮局产品进行了重大升级，提供用户从登录服务开始，直至访问服务结束，全程采用SSL保护模式功能。下面一起分享下关于三五邮局产品 全程SSL保护解决方案。
??一、众所周知，要实现全程HTTPS访问，首先就要解决SSL证书的问题。对于普通的应用服务来说，一个域名对应于一个服务，那么购 买、配置SSL证书完成HTTPS全程访问，并不是一件复杂的事情。而对于像我司这种专注于SAAS服务的公司来说，大多数客户都是通过自己的域名来登录 自己购买的服务的。所以多个域名就必须共享一个SSL证书（一个域名用户购买一个证书不可行）。所以按照类似多域名单SSL证书登录的模式，我们采用 HTTPS全程通过统一地址进行访问。
例如：mail.a.com访问webmail，mail.b.com访问webmail，则两个域名登录之后统一采用https://mail.serverhost.com进行访问。
二、我们的所有的产品线基于CAS的单点登录。所以在实现邮局产品的全程HTTPS访问时，就主要需要对Jasig?CAS?进行一定的业务处理。首先简单介绍下CAS实现的原理（详细的CAS知识，请自行google了解）。
1、CAS的核心思想是基于客户端Cookie服务共享机制。
2、CAS两个核心对象TGT，ST。TGT是CAS封装了客户端的Cookie对象，写入浏览器客户端的Cookie。ST是CAS服务端为每一个CAS客户端创建的一个票据。
3、所有的客户端服务的登录认证均跳转至CAS服务端，CAS服务端通过TGT判断用户是否完成登录验证。若没有TGT，则会到登陆页要求用户输入信息验 证，验证成功之后，CAS服务端会产生一个TGT对象，并写到浏览器客户端。同时为对应的服务创建ST，并作为参数跳转回请求认证的服务。对应的服务获取 到ST，再次到CAS服务端验证ST的有效性，若有效，即允许访问服务。
以上简单介绍了CAS的实现原理和流程，那么在需要HTTPS全程访问，我们就需要在ST上下功夫。
通过分析CAS的源码可以发现，CAS在验证成功之后，跳转到对应的服务时，是根据请求的参数Service，而同时其内部优先支持目标服务 （targetService）参数，因此我们采用了在登录验证时，若选择全程SSL保护，则会携带targetService参数引导CAS服务端跳转 到targetService（验证成功之后），并且以targetService生成ST。其中参数targetService参数即我们每一台服务器 HTTPS配置serverHost，这一步是关键。
完成上述targetService（HTTPS）的引导，即成功引导用户使用HTTPS访问邮局服务。
三、实现多个服务切换之后，切入邮局系统，仍然保持HTTPS访问。
我们主要采用了Cookie机制，当然你也可以采用Session机制，条条大道通罗马。在CAS服务端验证请求时，我们会根据 用户的选择，记录当前是否HTTPS全程访问到Cookie中，注意此时的Cookie，我们会记录到邮局服务下（而并非CAS服务下），并且是根目录， 有效期设置为浏览器的会话时效。这样，当用户切换不同服务之后，切回邮局，我们才能记住当前用户的SSL保护状态。
四、最后，谈谈HTTPS访问邮局服务过程，出现的一些问题。浏览器安全限制的问题，在IE8版本以下，HTTPS应用下，若是访问HTTP资源，则浏览器会提示安全限制。这个真的很影响用户的交互，你怎么看？必须解除。
因为三五邮局已经是一个非常庞大、成熟的系统，当然内部不免某些配置HTTP的资源，这就决定了我们接下来的工作是，消除系统内部所有的这些HTTP请 求。一是尽量把所有的资源请求路径相对化，采用相对路径；二是对于无法相对化的请求，尽量在客户端采用获取ServerName的方式来替代；当然，还有 一些外部系统嵌套的，那就要保证它也支持HTTPS咯，实在没办法的话，那就只能忍痛割爱。
以上为个人整个SSL保护实现的愚见，供诸君吐槽。
原文地址：浅谈邮局全程SSL保护的实现, 感谢原作者分享。