Ⅰ android 使用 HTTPS
如果你的项目的网络框架是okhttp，那么使用https还是挺简单的，因为okhttp默认支持HTTPS。 传送门
Android 使用 HTTPS 配置的步骤。
配置hostnameVerifier
2.step
配置 sslSocketFactory
调用 getSslSocketFactory(null,null,null) 即可。
3.step
设置OkhttpClient。
方法 getSslSocketFactory(null,null,null) 的第一个参数 本来要传入自签名证书的，当传入null 即可忽略自签名证书。
如果你想尝试不忽略自签名证书 你可以调用下面的方法获取 SSLSocketFactory。并设置到OkhttpClient中。
通过上面的几步配置即可使用https的自签名证书 和 单向验证的Https了。
Glide 访问Https的图片
1.step
在build.gradle 引入下面的aar
2.step
设置已经验证证书的的OkhttpClient 到Glide 既可。
END.
Ⅱ Android网络请求知识（三）授权，TCP/IP，HTTPS建立过程
由身份或持有的令牌确认享有的权限，登录过程实质上的目的也是为了确认权限。
Cookie是客户端给服务器用的，setCookie是服务器给客户端用的。cookie由服务器处理，客户端负责存储
客户端发送cookie：账户和密码
服务端收到后确认登录setCookie：sessionID=1，记下sessionID
客户端收到sessionID后记录，以后请求服务端带上对比记录下sessionID，说明已经登录
会话管理：登录状态，购物车
个性化：用户偏好，主题
Tracking：分析用户行为
XXS：跨脚本攻击，及使用javaScript拿到浏览器的cookie之后，发送到自己的网站，以这种方式来盗用用户Cookie。Server在发送Cookie时，敏感的Cookie加上HttpOnly，这样Cookie只能用于http请求，不能被JavaScript调用
XSRF:跨站请求伪造。Referer 从哪个网站跳转过来
两种方式：Basic和Bearer
首先第三方网站向授权网站申请第三方授权合作，拿到授权方颁发的client_id和client_secret（一般都是appid+appkey的方式）。
在这就过程中申请的client_secret是服务器持有的，安全起见不能给客户端，用服务端去和授权方获取用户信息，再传给客户端，包括④，⑤的请求过程也是需要加密的。这才是标准的授权过程。
有了access_token之后，就可以向授权方发送请求来获取用户信息
步骤分析就是上面的内容，这里把第4,6,8请求的参数分析一下
第④步参数：
response_type：指授权类型，必选，这里填固定值‘code’
client_id：指客户端id，必选，这里填在平台报备时获取的appid
redirect_uri：指重定向URI，可选
scope：指申请的权限范围，可选
state：指客户端当前状态，可选，若填了，则认证服务器会原样返回该值
第⑥步参数：
grant_type：指使用哪种授权模式，必选，这里填固定值‘authorization_code’
code：指从第⑤步获取的code，必选
redirect_uri：指重定向URI，必选，这个值需要和第④步中的redirect_uri保持一致
client_id：指客户端id，必选，这里填在平台报备时获取的appid
client_secret：指客户端密钥，必选，这里填在平台报备时获取的appkey
第⑧步参数：
access_token：指访问令牌，必选，这里填第⑦步获取的access_token
token_type：指令牌类型，必选，大小写不敏感，bearer类型 / mac类型
expires_in：指过期时间，单位秒，当其他地方已设置过期时间，此处可省略该参数
refresh_token：指更新令牌，可选，用即将过期token换取新token
scope：指权限范围，可选，第④步中若已申请过某权限，此处可省略该参数
我们在上面的第八步中会有refresh_token的参数，这个在实际操作中也比较常见
有时候我们在自己的项目中，将登陆和授权设计成类似OAuth2的过程，不过去掉Authorization code。登陆成功返回access_token，然后客户端再请求时，带上access_token。
我们常常会说到TCP/IP，那到底是什么呢。这就需要讲到网络分层模型。TCP在传输层，IP在网络层。那为什么需要分层？因为网络不稳定，导致需要重传的问题。为了提高传输效率我们就需要分块，在传输层中就会进行分块。TCP还有两个重要的内容就是三次握手，四次分手。
HTTPS 协议是由 HTTP 加上TLS/SSL协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护
1.客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表（所使用的加密算法及密钥长度），客户端随机数，hash算法。
2.服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件，服务端随机数。服务器的加密组件内容是从接收到客户端加密组件内筛选出来的。
3.之后服务器发送Certificate报文。报文中包含公开密钥证书。一般实际有三层证书嵌套，其实像下面图二直接用根证书机构签名也是可以的，但是一般根证书机构比较忙，需要类似中介的证书机构来帮助。
4.最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
5.SSL第一次握手结束后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
6.接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
7.客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密报文作为判定标准。
8.服务器同样发送Change Cipher Spec报文。
9.服务器同样发送Finished报文。
10.服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP响应。
11.应用层协议通信，即发送HTTP响应。
12.最后由客户端断开连接。断开连接时，发送close_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信。
利用客户端随机数，服务端随机数，per-master secret随机数生成master secret，再生成客户端加密密钥，服务端加密密钥，客户端MAC secert，服务端MAC secert。MAC secert用于做报文摘要，这样能够查知报文是否遭到篡改，从而保护报文的完整性。
Android网络请求知识（一）HTTP基础概念
Android网络请求知识（二）对称和非对称加密、数字签名，Hash，Base64编码
Android网络请求知识（三）授权，TCP/IP，HTTPS建立过程
Ⅲ android https和http有什么区别
HTTPS（Secure Hypertext Transfer Protocol）安全超文本传输协议
它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。
它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安全全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。）SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。
HTTPS和HTTP的区别：
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
http的连接很简单,是无状态的
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全
HTTPS解决的问题：
1 . 信任主机的问题. 采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候,客户度才信任次主机. 所以目前所有的银行系统网站,关键部分应用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全. 这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue, 客户端都是自己人,所以我们也就肯定信任该server.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥. 一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的. 第三方即使截获,也没有任何意义.因为他没有密钥. 当然窜改也就没有什么意义了.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还密钥和确认加密算法的需要.单握手就需要6/7 个往返.
i. 任何应用中,过多的round trip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.
ii. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示
Ⅳ android https安全吗
HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议，是一个安全通信通道，它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。android相关应用使用https会比http更加安全。网页链接
Ⅳ Android中怎么使用Https协议
android中使用http协议通信办法还是有好几种的，第一种是用socket自定义协议头，功能灵活但较为复杂。最简单的我觉得还是下面这种：HttpGet mHttpGet = new HttpGet(要访问的地址String);HttpResponse mHttpResponse;mHttpResponse = new DefaultHttpClient().execute(mHttpGet); if (mHttpResponse.getStatusLine().getStatusCode() == 200) { String result= EntityUtils .toString(mHttpResponse.getEntity()); }当然，过程中要注意的地方还有挺多的..字符集，转义之类的，访问参数之类的，要深入去探究了。
Ⅵ HTTP与HTTPS区别及Android证书配置
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
客户端会验证公钥是否有效。如果没有问题，就回生成一个随机值，并对其进行加密，（这个随机值其实就是对称加密的私钥）
服务端用私钥解密后，得到了客户端传过来的随机值（私钥），然后把内容进行对称加密。
首先用的是非对称加密。把公钥给客户端，私钥在服务端。客户端用公钥验证通过后，会生成私钥进行对称加密。然后传给后台。
为什么这么做呢。
图中的方法是验证服务端购买的证书。如果是信任所有证书的。这三个重写的方法不需要做操作。直接用默认即可。
详细解析 HTTP 与 HTTPS 的区别
非对称加密和对称加密的区别
如有错误。还望指正，非常感谢。
Ⅶ Android之网络—第二篇（Https原理）
Android之网络—第一篇（Http原理）
Android之网络—第二篇（Https原理）
Android之网络—第三篇（解读OkHttp）
Android之网络—第四篇（解读Retrofit）
说的通俗一点就是身披安全衣的Http，本质还是http，只是在http外层嵌套了一个SSL/TLS的安全层，该层做了一些数据的加解密处理。
在讲解Https原理之前，先做点准备工作，因为会涉及到SSL/TLS连接建立、SSL/TLS加解密方面的知识。所以会整体从网络架构和比较重要的知识点回顾下网络知识。
在讲解什么是SSL/TLS之前，回顾下TCP/IP协议的分层概念。通常一个网络的传输中间会经过很多的传输节点，才最终达到服务器。期间过程会包含数据的拆分和拼装、IP的解析、数据的传输等等操作，但是网络传输是很不稳定的，如果这次网络请求在中间的某一节点失败了，难道还要重新再发送一遍么？答案是不应该这么做。
为了网络传输的统一规范，就设计了这么一套网络通信的规范，每一层都专注做一件事情，即使当前失败了，也在这层做处理就可以了，尽量避免重发。
简单解释下，每层的含义：
通过上图发现，数据是由上往下传递后，再由下往回传递。这是怎么回事呢？总结就是：在 TCP / IP协议中数据先由上往下将数据装包，然后由下往上拆包。在装包的时候，每一层都会增加一些信息用于传输，这部分信息就叫报头，当上层的数据到达本层的时候，会将数据加上本层的报头打包在一起，继续往下传递。在拆包的时候，每一层将本层需要的报头读取后，就将剩下的数据往上传。
简要分析下传输过程：
这里简单总结下传输层的两种连接方式：TCP和UDP
三次握手：客户端主动打开连接，服务器被动打开连接。
四次挥手：客户端主动关闭，服务器被动关闭
说个概念性的东西就是，现代密码学分为对称加密和非对称加密，跟传统密码学不一样的地方就是，除了可以加密文字内容外，还可以用于各种二进制数据的加解密。
通信双方使用同一个密钥，使用加密算法配合上密钥来加密，解密时使用解密算法（加密过程的完全逆运算）配合密钥来进行解密。常用的经典算法：DES（56 位密钥，密钥太短而逐渐被弃用）、AES（128 位、192 位、256 位密钥，现在最流行）。
通信双方使用公钥和加密算法对数据进行加密得到密文；使用私钥和加密算法对数据进行解密得到原数据。常用的经典算法：RSA（可用于加密和签名）、DSA（仅用于签名，但速度更快）。
这个有什么用？其实这个就是后面Https加解密的原理。原理这么简单么？是的，就这么简单。但是要理解还得慢慢往下看。
A用自己的私钥通过加密算法得到的数据密文数据，这个数据就可以称为签过名。接收方B再用A提供的公钥通过加密算法就可以还原数据，从而就验证了数据的真实性。因为只有A一个人拥有自己的私钥。
到这里咱们就可以聊聊刚才中间人伪造数据是如何处理了。通过对称加密可以防止中间人偷窥数据，通过数字签名可以防止中间人篡改伪造数据。
但是完整版的签名信息需要将签名数据取Hash值，减少数据大小
好了，看完理解了上面的知识点，到这里我们可以慢慢分析Https是如何工作的了。
先来总结一句话：Https的本质就是在客户端和服务端之间用非对称加密协商出一套对称密钥，每次发送信息之前将内容加密，接收后解密，达到内容的加密传输。解释下，就是整个数据的传输过程是用对称加密的方式来传输的，只是密钥的生成是由客户端和服务端 在创建连接的时候 通过 非对称加密的方式 协商生成的。
那这里就会有一系列的问题啦：
Q：为什么不直接用非对称加密的方式直接加密呢？
A：因为非对称加密的计算过程是复杂的数学运算，太复杂了，很慢。
Q：哦哦，那既然使用对称加密的话，这个对称密钥是怎么来的？
A：在实际的场景中，服务端会对接N个客户端，这个对称密钥如果都使用同一个密钥来通信的话，肯定是不合理的，只要破解了其中一个，其他所有的都会被破解。所以整体的网络架构应该是使用不同加密方式用不同的密钥来进行数据传输的。模型如下图
Q：但是在网络场景中，对称加密的密钥是不能直接在网络上传输的。服务端和客户端是如何都知道的呢？
A：这个是服务端和客户端一起协商根据只有它俩知道的规则分别生成，就不用通过网络传输啦。
Q：如果保证它俩协商出来的密钥不被破解呢？
A：当然是使用非对称加密的方式啦。通过之前的加密知识，可以知道非对称加密是目前来说是绝对安全的。而且一个私钥可以有多个公钥，正好满足一个服务端对N个客户端的场景。模型如下图：
实际在协商通讯的过程中，这个公钥是服务端给客户端发送的。而且需要注意 这个公钥是用来协商生成对称密钥的，不是用来做数据的加密传输的 。
Q：哦哦，原来是这样，但是这样子还是有问题啊，客户端与服务端在协商生成密钥的过程中为了保证数据被偷窥和被篡改的风险，一般会要求有两套公钥和私钥分别做加解密和签名验证处理的，上面的模型只有一套公钥和私钥，没法规避数据被被篡改的风险呀。
A：能提出这个问题，说明之前的学习理解得很好。从上面的模型，可以保证在协商的过程中客户端A/B/C/D分别向服务器传输的数据是安全。但是服务器发送给客户端的数据是如何保证的呢？换句话说就是，客户端如何验证数据是服务端发送过来的，而不是被中间假冒掉包的数据。这不就是之前讲的数字签名的内容么？而实际情况中，就是通过CA证书来处理这个问题的。
Q：那这个CA证书是怎么验证的呢？
A：请看下面的CA证书的分析。
回归之前的分析，我们的问题点卡在了“服务器发送给客户端的数据是如何保证的呢”。对吧。实际上在协商通信的过程中，服务端会先给客户端下发证书信息，这个证书信息里面会包含非对称加密的公钥。但是考虑一个问题，如何保证这个公钥就是客户端要的公钥呢？或者说怎么保证这个证书就是真实的证书，而不是被篡改假冒的证书。只有验证了这一步，客户端才完全信赖服务端，才给服务器发消息，也才接受服务器的消息。这时候就只需要一套公钥和私钥客户端和服务端就可以通信了。
Q：那客户端如何验证服务端下发的证书和公钥是正确的呢？
A：先换个概念，将证书里面的公钥假设为一串数据。要验证这个数据，只需要提供这串数据的签名以及加密这段数据的签名的私钥对应的公钥就可以了，如下图框框所示。
Q：那这样子又有另外的一个问题产生了怎么去验证 这段数据的签名的私钥对应的公钥 了？
A：同样的，也是需要提供对应的签名和对应签名的私钥对应的公钥。
Q：但是这样子下去就会变成一个循环了，怎么办？
其实在这里还会有一个场景问题：第三方签发机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方签发机构的公钥进行解密。
A：是的，为处理这个问题，就需要讲一个根证书的东西。先举个例子：假设你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。同样的，Https请求验证时，会用到手机操作系统内置的根证书去验证这个证书的真伪的。
到这里就简要分析完了证书的验证过程。证书会包含很多信息，包括服务器公钥，服务器名字，服务器地区等等信息。这个是没法篡改的。其中对Https连接来说最重要的就是服务器的公钥。
之前学习完TCP的连接过程，现在我们开始来唠唠Https连接。什么是Https连接呢？准确来说就是SSL/TLS加解密层的连接。
大致的建立流程：
详细的建立流程：
客户端MAC secret，服务端MAC secret的主要作用：用来认证这个消息是正确的，完整的，解决对称加密方式没法验证消息的缺点。
至此完整的Https在TLS层连接过程分析完毕。
如果觉得我的文章对你有帮助，请随意赞赏。您的支持将鼓励我继续创作！
Ⅷ Android面试笔记——HTTP/HTTPS
HTTP和HTTPS是面试常问的问题，内容比较多而且复杂，HTTPS里面的细节很多，本文只是把主要的东西写出来，想要弄懂HTTPS还是要多看几篇博文，自己动手走一遍把各个攻击的case搞明白。
HTTP 是超⽂本传输协议，也就是HyperText Transfer Protocol。
Host 字段 ：客户端发送请求时，⽤来指定服务器的域名。 Host: www..com
Content-Length 字段 ：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。 Content-Length: 1000
Connection 字段 ：Connection 字段最常用于客户端要求服务器使⽤ TCP 持久连接，以便其他请求复⽤。 HTTP/1.1 版本的默认连接都是持久连接，但为了兼容⽼版本的 HTTP，需要指定 Connection ⾸部字段的值为Keep-Alive 。
Content-Type 字段 ：Content-Type 字段⽤于服务器回应时，告诉客户端，本次数据是什么格式 。 Content-Type: text/html; charset=utf-8
Content-Encoding 字段 ：Content-Encoding 字段说明数据的压缩⽅法。表示服务器返回的数据使用了什么压缩格式 。客户端在请求时，⽤ Accept-Encoding 字段说明自己可以接受哪些压缩⽅法。 Accept-Encoding: gzip, deflate
下图为访问网络的返回字段
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP 。
UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的⼀个丢包全部重传问题。
UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
HTTPS 采⽤的是 对称加密和⾮对称加密结合 的“混合加密”⽅式：
采⽤“混合加密”的⽅式的原因：
摘要算法⽤来实现 完整性 ，能够为数据⽣成独⼀⽆⼆的“指纹”，⽤于校验数据的完整性，解决了篡改的⻛险。
客户端在发送明⽂之前会通过摘要算法算出明文的“指纹”，发送的时候把“指纹 + 明文”⼀同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过⽐较客户端携带的“指纹”和当前算出的“指纹”做⽐较，若“指纹”相同，说明数据是完整的。
客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密文后，⽤⾃⼰的私钥解密。这就存在些问题，如何保证公钥不被篡改和信任度？
所以这⾥就需要借助第三⽅权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。
通过数字证书的⽅式保证服务器公钥的身份，解决冒充的⻛险 。
证书签名和验证过程 ：
两种情况 ：
Ⅸ android 怎么信任https
因为最近公司的open api服务器访问协议换成了https，所以 android 在使用okhttp 走https 访问的时候遇到了证书信任的问题，
在这里把我走过的弯路记下来，一如既往的话不多说，上码：
OkHttpClient sClient = new OkHttpClient();
// 设置超时时间
sClient.setConnectTimeout(8000, TimeUnit.MILLISECONDS);
sClient.setReadTimeout(8000, TimeUnit.MILLISECONDS);
// 注册拦截器
sClient.interceptors().add(new BaseInterceptor(context));
第一种方式：
sClient.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
运行结果：
javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:410)
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.squareup.okhttp.Connection.connectTls(Connection.java:235)
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.squareup.okhttp.Connection.connectSocket(Connection.java:199)
11-26 11:17:57.264 17106-1726