OpenSSL

kubectl create secret tls example-secret --key cert/xxx.key --cert cert/xxx.pem apiVersion: extensions/v1beta1 kind: Ingress metadata: name: example spec: tls: hosts: www.example.com secretName: example-secret rules: host: www.example.com http: paths: backend: serviceName: example servicePort: 80 来源： oschina 链接： https://my.oschina.net/u/4341956/blog/4809203

前言 Java对象是在JVM中产生的，若要将其进行传输或保存到硬盘，就要将对象转换为可传输的文件流。而目前Java对象的转换方式有： 利用Java的序列化功能序列成字节(字节流)，一般是需要加密传输时使用。 将对象包装成JSON字符串（字符流），一般使用JSON工具进行转换 。 protoBuf工具(二进制)，性能好，效率高，字节数很小，网络传输节省IO。但二进制格式可读性差。 一、序列化基础 序列化：Serialization（序列化）是一种将对象以一连串的字节描述的过程 反序列化：反序列化deserialization是一种将这些字节重建成一个对象的过程 序列化机制算法： 所有保存到磁盘中的对象都有一个序列化编号 当程序试图序列化一个对象时，程序先检查该对象是否已经被序列化过。如果从未被序列化过，系统就会将该对象转换成字节序列并输出；如果已经序列化过，将直接输出一个序列化编号。 1、应用场景 持久化对象 ：把对象的字节序列永久地保存到硬盘上 Java中能够在JVM中创建可复用的Java对象，但只用JVM运行时，对象才能存在，即对象的生命周期不可能比JVM生命周期更长。但实际情况可能遇到需要当JVM停止时也需要对象依旧存在，因而就需要对对象进行持久化，并在JVM停止的情况下，能够对保存的对象进行持久化。 对象复制 ：通过序列化，将对象保存在内存中

目录 1. 前言 2. 细读官方手册 3. 短信接口SDK包下载和配置 3.1 SDK下载 （1）官方链接下载 （2）composer下载 3.2 封装发送手机短信验证码功能类 3.2.1 密钥举例 3.2.2 封装调用SDK类 3.2.3 测试用例实战 3.2.4 测试用例结果 3.2.5将测试用例封装成常用类 3.2.6界面可视化 4. 总结 1.前言 之前我写过一篇‘发送手机短信验证实战’，用的是云之讯平台的短信接口，但相比而言，目前市面上用的大多是阿里云和腾讯云的短信接口，刚好，我公司也使用阿里云的短信接口（新版SDK），下面我们一起来进行阿里云短信接口的调用和需求功能封装吧！ 代码分享： https://github.com/mtdgclub/aliyunSmsDemo 2.细读官方手册 由手册我们可以知道，阿里云为我们提供了两种短信发送接口： SendSms接口是短信发送接口，支持在一次请求中向多个不同的手机号码发送同样内容的短信。 SendBatchSms接口 是 在一次请求中分别向多个不同的手机号码发送不同签名和模版内容的短信 。 而我这里主要用的是 SendSms接口 。 官方入门手册： https://helpcdn.aliyun.com/document_detail/53111.html SendSms接口 介绍： https://help.aliyun

前言： 前面介绍了RSA公钥加密算法，而在公钥加密体系中，另一类重要的加密体制是基于离散对数的难解性，如ECC椭圆曲线加密、Diffie-Hellman算法、ElGamal算法等。为了解决离散对数问题，我们需要先学习《近世代数》。 本文涉及知识点实操练习—— 密码学原理 （密码学是研究如何隐密地传递信息的学科。在现代特别指对信息以及其传输的数学性研究，常被认为是数学和计算机科学的分支，和信息论也密切相关。密码学是信息安全等相关议题，如认证、访问控制的核心。 代数基本知识: 1.群 2.环 3.域 4.有限域GF() 5.多项式环 群： 定义： 设G是非空集合，若在G内定义一种代数运算$\bigodot$，且满足下列4个条件，则称G（对运算$\bigodot$）构成一个群： (1) 封闭性：对任意的a,b $\epsilon$ G，恒有 a$\bigodot$b $\epsilon$ G; (2) 结合律：对任意的a,b,c $\epsilon$ G，恒有 (a$\bigodot$b)$\bigodot$c = a$\bigodot$(b$\bigodot$c) (3) 有单位元：存在e $\epsilon$ G，对任意的a $\epsilon$ G,有 a$\bigodot$e=e$\bigodot$a=a (4) 每个元存在逆元：对任意a $\epsilon$ G,存在b $

简介： 让天下没有打不开的小程序！！！ 在我们集成 mPaaS 插件并使用小程序的过程中，很多开发者遇到了打不开小程序的问题。今天就举例说明，开发者在完成基本接入后，尝试打开 H5 应用，但容器页面显示错误提示“设置标签”时，应该如何解决。 常见原因 mPaaS 框架在打开一个H5应用前，首先需要获知该应用离线包的基本信息。 因此客户端会主动通过RPC接口alipay.client.getUnionResource去拉取离线包信息。如果离线包信息获取失败，或没有命中要打开的目标应用，容器会提示错误 “系统繁忙，请稍后再试”。 针对这类问题，排查方向包括：检查 RPC 请求是否正常、检查环境和离线包发布是否匹配等。 问题排查步骤 （一）检查 RPC 请求是否正常 客户端需要主动拉取离线包信息，而拉取过程依赖 RPC 请求，如果RPC 链路存在问题，则无法正常获取离线包信息，导致加载失败。要确认 RPC 请求是否存在问题，需要在 Xcode 控制台中搜索 alipay.client.getUnionResource 观察 RPC 请求是否正常返回。如果存在错误，一般的错误代码包括 7XXX 或 3XXX 系列等，例如： 正常返回样例（result-status 为 1000）： Demo[83767:2555863] [mPaaSLog] APMobileNetwork alipay

当你初次创建新的 Centos 服务器的时候， Centos 默认的配置安全性和可用性上会存在一点缺陷（运维人员往往会有初始化的脚本）。为了增强服务器的安全性和可用性，有些配置你应该尽快地完成。 这篇文章大致从这方面去讲 - 账号安全 - ssh 安全 - 防火墙 - 交换区文件(swap file) 用户密码安全 关于 root 用户 root 用户是在linux环境下拥有非凡权限的的超级管理员。因为root用户的权限很高，所以在日常使用中 不建议 使用。这是因为 root 用户能做出一些非常有破坏性的行为，甚至是事故。（比如是臭名昭彰的 rm -rf / ，或者你会对这篇文章 《Linux 中如何避免 rm -rf /*》 感兴趣） 下一步，我们为了日常工作会设置一个权限较小的替代用户。我们会教你当你需要更大的权限的时候怎样获取。 创建一个新的用户 这个例子会创建一个用户叫 demo，你可以替换成你喜欢的用户名: adduser demo 下一步，为新的用户分配密码（再次说明，用你刚创建的用户替换demo） passwd demo 输入一个强密码，然后再重复输入以完成验证。 用户权限 现在，我们已经有了一个普通权限的用户。然而我们有时需要执行一些管理员任务。 为了避免要注销普通用户，然后用 root 用户重新登录，Linux 中有个优雅的解决方式，系统授权特定用户或用户组作为

苹果电脑远程连接SSH出现如下问题： @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:7Mgj5zkh6hldF8w3uw0Bqk5aJyXmOuotiZZpVMdJh3g. Please contact your system administrator. Add correct host key in /var/root/.ssh/known_hosts to get rid of

原来发布在掘金，搬过来好了。 微信小程序在PC端是加密存储的，如果直接打开是看不到什么有用的信息的，需要经过解密才可以看到包内具体的内容。本文使用nodejs实现解密算法，主要涉及到crypto, commander, chalk三个包的使用。 小程序的源码在哪里 PC端打开过的小程序会被缓存到本地微信文件的默认保存位置，可以通过微信PC端=>更多=>设置查看： 进入默认保存位置下的/WeChat Files/WeChat Files/Applet文件夹，可以看到该目录下有一系列前缀为wx的文件（文件名其实是小程序的appid），这些就是我们打开过的小程序啦： 进入其中某个小程序的文件夹，我们可以看到一个名字为一串数字的文件夹。点进这个文件夹， 就可以看到一个__APP__.wxapkg文件，也就是小程序对应的代码啦： 然而，当我们打开这个文件之后却发现是这样的： WTF 这能看出来个🔨。很明显，这个文件是经过加密的，需要解密才能看到我们想看到的东西。 PC端小程序是怎么被加密的 这里参考了一位大佬用Go语言写的 PC端wxapkg解密代码 。整理一下的话，加密流程是这样的： 首先将明文代码在第1024字节处一分为二，前半部分使用CBC模式的AES加密，后半部分则直接进行异或。最后，将加密后的两节拼接起来，并在最前边写入固定的字符串："V1MMWX"。 所以，我们打开__APP__

● 请问TCP三次握手是怎样的？ 参考回答： 1.客户端发送syn0给服务器 2.服务器收到syn0，回复syn1,ack(syn0+1) 3.客户端收到syn1，回复ack(syn1+1) ● 请问tcp握手为什么两次不可以？为什么不用四次？ 参考回答： 两次不可以：tcp是全双工通信，两次握手只能确定单向数据链路是可以通信的，并不能保证反向的通信正常 不用四次： 本来握手应该和挥手一样都是需要确认两个方向都能联通的，本来模型应该是： 1.客户端发送syn0给服务器 2.服务器收到syn0，回复ack(syn0+1) 3.服务器发送syn1 4.客户端收到syn1，回复ack(syn1+1) 因为tcp是全双工的，上边的四部确认了数据在两个方向上都是可以正确到达的，但是2，3步没有没有上下的联系，可以将其合并，加快握手效率，所有就变成了3步握手。 ● 请你来说一下TCP拥塞控制？ 参考回答： 发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。 过程cwnd的大小呈指数增长，直到超过慢启动门限