Skip to main content

Home/ Larvata/ Group items tagged ssl

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
張 旭

cryptography - What's the difference between SSL, TLS, and HTTPS? - Information Securit... - 0 views

security.stackexchange.com/...ence-between-ssl-tls-and-https

security ssl system https

shared by 張 旭 on 23 Jun 17 - No Cached
  • TLS is the new name for SSL
  • HTTPS is HTTP-within-SSL/TLS
  • SSL (TLS) establishes a secured, bidirectional tunnel for arbitrary binary data between two hosts
  • ...10 more annotations...
  • HTTP is meant to run over a bidirectional tunnel for arbitrary binary data; when that tunnel is an SSL/TLS connection, then the whole is called "HTTPS".
  • "SSL" means "Secure Sockets Layer".
  • "TLS" means "Transport Layer Security".
  • The name was changed to avoid any legal issues with Netscape so that the protocol could be "open and free" (and published as a RFC).
    • 張 旭
      張 旭 on 23 Jun 17
       
      看起來其實就指同一件事，只是講 TLS 可以避開 SSL 這個有產權糾紛的名諱。
  • not just Internet-based sockets
  • "HTTPS" is supposed to mean "HyperText Transfer Protocol Secure",
  • Other protocol acronyms have been built the same way, e.g. SMTPS, IMAPS, FTPS... all of them being a bare protocol that "got secured" by running it within some SSL/TLS.
  • To make the confusing perfect: SSL (secure socket layer) often refers to the old protocol variant which starts with the handshake right away and therefore requires another port for the encrypted protocol such as 443 instead of 80.
  • TLS (transport layer security) often refers to the new variant which allows to start with an unencrypted traditional protocol and then issuing a command (usually STARTTLS) to initialize the handshake.
  • Whether you use SSL or TLS for this depends on the configuration of your browser and of the server (there usually is an option to allow SSLv2, SSLv3 or TLS 1.x).
crazylion lee

BearSSL - 0 views

bearssl.org

openssl ssl tls

shared by crazylion lee on 11 Nov 16 - No Cached
  • crazylion lee on 11 Nov 16
     
    "BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C. It aims at offering the following features: Be correct and secure. In particular, insecure protocol versions and choices of algorithms are not supported, by design; cryptographic algorithm implementations are constant-time by default. Be small, both in RAM and code footprint. For instance, a minimal server implementation may fit in about 20 kilobytes of compiled code and 25 kilobytes of RAM. Be highly portable. BearSSL targets not only "big" operating systems like Linux and Windows, but also small embedded systems and even special contexts like bootstrap code. Be feature-rich and extensible. SSL/TLS has many defined cipher suites and extensions; BearSSL should implement most of them, and allow extra algorithm implementations to be added afterwards, possibly from third parties."
張 旭

Public Key Infrastructure (PKI) Overview - 0 views

www.sslshopper.com/frastructure-pki-overview.html

security https ssl

shared by 張 旭 on 19 Jan 19 - No Cached
  • A PKI allows you to bind public keys (contained in SSL certificates) with a person in a way that allows you to trust the certificate.
  • Public Key Infrastructures, like the one used to secure the Internet, most commonly use a Certificate Authority (also called a Registration Authority) to verify the identity of an entity and create unforgeable certificates.
  • An SSL Certificate Authority (also called a trusted third party or CA) is an organization that issues digital certificates to organizations or individuals after verifying their identity.
  • ...9 more annotations...
  • An SSL Certificate provides assurances that we are talking to the right server, but the assurances are limited.
  • In PKI, trust simply means that a certificate can be validated by a CA that is in our trust store.
  • An SSL Certificate in a PKI is a digital document containing a public key, entity information, and a digital signature from the certificate issuer.
  • it is much more practical and secure to establish a chain of trust to the Root certificate by signing an Intermediate certificate
  • A trust store is a collection of Root certificates that are trusted by default.
  • there are four primary trust stores that are relied upon for the majority of software: Apple, Microsoft, Chrome, and Mozilla.
  • a revocation system that allows a certificate to be listed as invalid if it was improperly issued or if the private key has been compromised.
  • Online Certificate Status Protocol (OCSP)
  • Certificate Revocation List (CRL)
crazylion lee

/bin/bash based SSL/TLS tester: testssl.sh - 0 views

testssl.sh

SSL

shared by crazylion lee on 29 Sep 15 - No Cached
  • crazylion lee on 29 Sep 15
     
    "testssl.sh is a free command line tool which checks a server's service on any port for the support of TLS/SSL ciphers, protocols as well as recent cryptographic flaws and more. "
snow9816

CentOS 5.5 安裝 Apache 2.2.x (教學筆記) - Soul & Shell Blog - 0 views

blog.toright.com/...5%AD%B8%E7%AD%86%E8%A8%98.html

apache openssl devel

shared by snow9816 on 21 Sep 16 - No Cached
  • 使用 "--enable-ssl" 但是找不到可用的 header 進行編譯，可透過安裝 SSL 套件
  • No recognized SSL/TLS toolkit detected
  • yum install openssl-devel
crazylion lee

jvehent/cipherscan - 0 views

github.com/cipherscan

https ssl

shared by crazylion lee on 20 Nov 14 - No Cached
  • crazylion lee on 20 Nov 14
     
    "A very simple way to find out which SSL ciphersuites are supported by a target."
張 旭

What is a CSR (Certificate Signing Request)? - 0 views

www.sslshopper.com/rtificate-signing-request.html

security https ssl

shared by 張 旭 on 19 Jan 19 - No Cached
  • usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country.
  • A private key is usually created at the same time that you create the CSR, making a key pair.
  • CSR or Certificate Signing request is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate
  • ...6 more annotations...
  • A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key.
  • The certificate created with a particular CSR will only work with the private key that was generated with it.
  • Most CSRs are created in the Base-64 encoded PEM format.
  • generate a CSR and private key on the server that the certificate will be used on.
  • openssl req -in server.csr -noout -text
  • The bit-length of a CSR and private key pair determine how easily the key can be cracked using brute force methods.
張 旭

SSL Certificate Features - 0 views

www.sslshopper.com/ssl-certificate-features.html

security https ssl

shared by 張 旭 on 19 Jan 19 - No Cached
  • A certificate authority issues certificates in the form of a tree structure.
  • All certificates below the root certificate inherit the trustworthiness of the root certificate.
  • Any certificate signed by a trusted root certificate will also be trusted.
  • ...9 more annotations...
  • the browser has all of the certificates in the chain to link it up to a trusted root certificate.
  • Any certificate in between your certificate and the root certificate is called a chain or intermediate certificate.
  • These must be installed to the web server with the primary certificate for your web site so that user's browers can link your certificate to a trusted authority.
  • Chain Certificate
  • Intermediate Certificate
  • Root Certificate
  • EV (Extended Validation) certificate
  • wildcard certificate
  • domain-validated certificate
  • 張 旭 on 19 Jan 19
     
    "A certificate authority issues certificates in the form of a tree structure."
張 旭

Helm | - 0 views

helm.sh/using_helm

kubernetes helm system

shared by 張 旭 on 17 Jul 19 - No Cached
  • Helm will figure out where to install Tiller by reading your Kubernetes configuration file (usually $HOME/.kube/config). This is the same file that kubectl uses.
  • kubectl cluster-info
  • Role-Based Access Control (RBAC) enabled
  • ...133 more annotations...
  • initialize the local CLI
  • install Tiller into your Kubernetes cluster
  • helm install
  • helm init --upgrade
  • By default, when Tiller is installed, it does not have authentication enabled.
  • helm repo update
  • Without a max history set the history is kept indefinitely, leaving a large number of records for helm and tiller to maintain.
  • helm init --upgrade
  • Whenever you install a chart, a new release is created.
  • one chart can be installed multiple times into the same cluster. And each can be independently managed and upgraded.
  • helm list function will show you a list of all deployed releases.
  • helm delete
  • helm status
  • you can audit a cluster’s history, and even undelete a release (with helm rollback).
  • the Helm server (Tiller).
  • The Helm client (helm)
  • brew install kubernetes-helm
  • Tiller, the server portion of Helm, typically runs inside of your Kubernetes cluster.
  • it can also be run locally, and configured to talk to a remote Kubernetes cluster.
  • Role-Based Access Control - RBAC for short
  • create a service account for Tiller with the right roles and permissions to access resources.
  • run Tiller in an RBAC-enabled Kubernetes cluster.
  • run kubectl get pods --namespace kube-system and see Tiller running.
  • helm inspect
  • Helm will look for Tiller in the kube-system namespace unless --tiller-namespace or TILLER_NAMESPACE is set.
  • For development, it is sometimes easier to work on Tiller locally, and configure it to connect to a remote Kubernetes cluster.
  • even when running locally, Tiller will store release configuration in ConfigMaps inside of Kubernetes.
  • helm version should show you both the client and server version.
  • Tiller stores its data in Kubernetes ConfigMaps, you can safely delete and re-install Tiller without worrying about losing any data.
  • helm reset
  • The --node-selectors flag allows us to specify the node labels required for scheduling the Tiller pod.
  • --override allows you to specify properties of Tiller’s deployment manifest.
  • helm init --override manipulates the specified properties of the final manifest (there is no “values” file).
  • The --output flag allows us skip the installation of Tiller’s deployment manifest and simply output the deployment manifest to stdout in either JSON or YAML format.
  • By default, tiller stores release information in ConfigMaps in the namespace where it is running.
  • switch from the default backend to the secrets backend, you’ll have to do the migration for this on your own.
  • a beta SQL storage backend that stores release information in an SQL database (only postgres has been tested so far).
  • Once you have the Helm Client and Tiller successfully installed, you can move on to using Helm to manage charts.
  • Helm requires that kubelet have access to a copy of the socat program to proxy connections to the Tiller API.
  • A Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster.
  • helm init --client-only
  • helm init --dry-run --debug
  • A panic in Tiller is almost always the result of a failure to negotiate with the Kubernetes API server
  • Tiller and Helm have to negotiate a common version to make sure that they can safely communicate without breaking API assumptions
  • helm delete --purge
  • Helm stores some files in $HELM_HOME, which is located by default in ~/.helm
  • A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster.
  • it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.
  • A Repository is the place where charts can be collected and shared.
  • Set the $HELM_HOME environment variable
  • each time it is installed, a new release is created.
  • Helm installs charts into Kubernetes, creating a new release for each installation. And to find new charts, you can search Helm chart repositories.
  • chart repository is named stable by default
  • helm search shows you all of the available charts
  • helm inspect
  • To install a new package, use the helm install command. At its simplest, it takes only one argument: The name of the chart.
  • If you want to use your own release name, simply use the --name flag on helm install
  • additional configuration steps you can or should take.
  • Helm does not wait until all of the resources are running before it exits. Many charts require Docker images that are over 600M in size, and may take a long time to install into the cluster.
  • helm status
  • helm inspect values
  • helm inspect values stable/mariadb
  • override any of these settings in a YAML formatted file, and then pass that file during installation.
  • helm install -f config.yaml stable/mariadb
  • --values (or -f): Specify a YAML file with overrides.
  • --set (and its variants --set-string and --set-file): Specify overrides on the command line.
  • Values that have been --set can be cleared by running helm upgrade with --reset-values specified.
  • Chart designers are encouraged to consider the --set usage when designing the format of a values.yaml file.
  • --set-file key=filepath is another variant of --set. It reads the file and use its content as a value.
  • inject a multi-line text into values without dealing with indentation in YAML.
  • An unpacked chart directory
  • When a new version of a chart is released, or when you want to change the configuration of your release, you can use the helm upgrade command.
  • Kubernetes charts can be large and complex, Helm tries to perform the least invasive upgrade.
  • It will only update things that have changed since the last release
  • $ helm upgrade -f panda.yaml happy-panda stable/mariadb
  • deployment
  • If both are used, --set values are merged into --values with higher precedence.
  • The helm get command is a useful tool for looking at a release in the cluster.
  • helm rollback
  • A release version is an incremental revision. Every time an install, upgrade, or rollback happens, the revision number is incremented by 1.
  • helm history
  • a release name cannot be re-used.
  • you can rollback a deleted resource, and have it re-activate.
  • helm repo list
  • helm repo add
  • helm repo update
  • The Chart Development Guide explains how to develop your own charts.
  • helm create
  • helm lint
  • helm package
  • Charts that are archived can be loaded into chart repositories.
  • chart repository server
  • Tiller can be installed into any namespace.
  • Limiting Tiller to only be able to install into specific namespaces and/or resource types is controlled by Kubernetes RBAC roles and rolebindings
  • Release names are unique PER TILLER INSTANCE
  • Charts should only contain resources that exist in a single namespace.
  • not recommended to have multiple Tillers configured to manage resources in the same namespace.
  • a client-side Helm plugin. A plugin is a tool that can be accessed through the helm CLI, but which is not part of the built-in Helm codebase.
  • Helm plugins are add-on tools that integrate seamlessly with Helm. They provide a way to extend the core feature set of Helm, but without requiring every new feature to be written in Go and added to the core tool.
  • Helm plugins live in $(helm home)/plugins
  • The Helm plugin model is partially modeled on Git’s plugin model
  • helm referred to as the porcelain layer, with plugins being the plumbing.
  • helm plugin install https://github.com/technosophos/helm-template
  • command is the command that this plugin will execute when it is called.
  • Environment variables are interpolated before the plugin is executed.
  • The command itself is not executed in a shell. So you can’t oneline a shell script.
  • Helm is able to fetch Charts using HTTP/S
  • Variables like KUBECONFIG are set for the plugin if they are set in the outer environment.
  • In Kubernetes, granting a role to an application-specific service account is a best practice to ensure that your application is operating in the scope that you have specified.
  • restrict Tiller’s capabilities to install resources to certain namespaces, or to grant a Helm client running access to a Tiller instance.
  • Service account with cluster-admin role
  • The cluster-admin role is created by default in a Kubernetes cluster
  • Deploy Tiller in a namespace, restricted to deploying resources only in that namespace
  • Deploy Tiller in a namespace, restricted to deploying resources in another namespace
  • When running a Helm client in a pod, in order for the Helm client to talk to a Tiller instance, it will need certain privileges to be granted.
  • SSL Between Helm and Tiller
  • The Tiller authentication model uses client-side SSL certificates.
  • creating an internal CA, and using both the cryptographic and identity functions of SSL.
  • Helm is a powerful and flexible package-management and operations tool for Kubernetes.
  • default installation applies no security configurations
  • with a cluster that is well-secured in a private network with no data-sharing or no other users or teams.
  • With great power comes great responsibility.
  • Choose the Best Practices you should apply to your helm installation
  • Role-based access control, or RBAC
  • Tiller’s gRPC endpoint and its usage by Helm
  • Kubernetes employ a role-based access control (or RBAC) system (as do modern operating systems) to help mitigate the damage that can be done if credentials are misused or bugs exist.
  • In the default installation the gRPC endpoint that Tiller offers is available inside the cluster (not external to the cluster) without authentication configuration applied.
  • Tiller stores its release information in ConfigMaps. We suggest changing the default to Secrets.
  • release information
  • charts
  • charts are a kind of package that not only installs containers you may or may not have validated yourself, but it may also install into more than one namespace.
  • As with all shared software, in a controlled or shared environment you must validate all software you install yourself before you install it.
  • Helm’s provenance tools to ensure the provenance and integrity of charts
  • 張 旭 on 17 Jul 19
     
    "Helm will figure out where to install Tiller by reading your Kubernetes configuration file (usually $HOME/.kube/config). This is the same file that kubectl uses."
張 旭

Ingress - Kubernetes - 0 views

kubernetes.io/...ingress

kubernetes networking network ingress

shared by 張 旭 on 04 Jul 19 - No Cached
  • An API object that manages external access to the services in a cluster, typically HTTP.
  • load balancing
  • SSL termination
  • ...62 more annotations...
  • name-based virtual hosting
  • Edge routerA router that enforces the firewall policy for your cluster.
  • Cluster networkA set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes networking model.
  • A Kubernetes ServiceA way to expose an application running on a set of Pods as a network service. that identifies a set of Pods using labelTags objects with identifying attributes that are meaningful and relevant to users. selectors.
  • Services are assumed to have virtual IPs only routable within the cluster network.
  • Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
  • Traffic routing is controlled by rules defined on the Ingress resource.
  • An Ingress can be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting.
  • Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.
  • You must have an ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.
  • As with all other Kubernetes resources, an Ingress needs apiVersion, kind, and metadata fields
  • Ingress frequently uses annotations to configure some options depending on the Ingress controller,
  • Ingress resource only supports rules for directing HTTP traffic.
  • An optional host.
  • A list of paths
  • A backend is a combination of Service and port names
  • has an associated backend
  • Both the host and path must match the content of an incoming request before the load balancer directs traffic to the referenced Service.
  • HTTP (and HTTPS) requests to the Ingress that matches the host and path of the rule are sent to the listed backend.
  • A default backend is often configured in an Ingress controller to service any requests that do not match a path in the spec.
  • An Ingress with no rules sends all traffic to a single default backend.
  • Ingress controllers and load balancers may take a minute or two to allocate an IP address.
  • A fanout configuration routes traffic from a single IP address to more than one Service, based on the HTTP URI being requested.
  • nginx.ingress.kubernetes.io/rewrite-target: /
  • describe ingress
  • get ingress
  • Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
  • route requests based on the Host header.
  • an Ingress resource without any hosts defined in the rules, then any web traffic to the IP address of your Ingress controller can be matched without a name based virtual host being required.
  • secure an Ingress by specifying a SecretStores sensitive information, such as passwords, OAuth tokens, and ssh keys. that contains a TLS private key and certificate.
  • Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination.
  • An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others.
  • persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can instead get these features through the load balancer used for a Service.
  • review the controller specific documentation to see how they handle health checks
  • edit ingress
  • After you save your changes, kubectl updates the resource in the API server, which tells the Ingress controller to reconfigure the load balancer.
  • kubectl replace -f on a modified Ingress YAML file.
  • Node: A worker machine in Kubernetes, part of a cluster.
  • in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.
  • Edge router: A router that enforces the firewall policy for your cluster.
  • a gateway managed by a cloud provider or a physical piece of hardware.
  • Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes networking model.
  • Service: A Kubernetes Service that identifies a set of Pods using label selectors.
  • An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting.
  • An Ingress does not expose arbitrary ports or protocols.
  • You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.
  • The name of an Ingress object must be a valid DNS subdomain name
  • The Ingress spec has all the information needed to configure a load balancer or proxy server.
  • Ingress resource only supports rules for directing HTTP(S) traffic.
  • An Ingress with no rules sends all traffic to a single default backend and .spec.defaultBackend is the backend that should handle requests in that case.
  • If defaultBackend is not set, the handling of requests that do not match any of the rules will be up to the ingress controller
  • A common usage for a Resource backend is to ingress data to an object storage backend with static assets.
  • Exact: Matches the URL path exactly and with case sensitivity.
  • Prefix: Matches based on a URL path prefix split by /. Matching is case sensitive and done on a path element by element basis.
  • multiple paths within an Ingress will match a request. In those cases precedence will be given first to the longest matching path.
  • Hosts can be precise matches (for example “foo.bar.com”) or a wildcard (for example “*.foo.com”).
  • No match, wildcard only covers a single DNS label
  • Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class.
  • secure an Ingress by specifying a Secret that contains a TLS private key and certificate.
  • The Ingress resource only supports a single TLS port, 443, and assumes TLS termination at the ingress point (traffic to the Service and its Pods is in plaintext).
  • TLS will not work on the default rule because the certificates would have to be issued for all the possible sub-domains.
  • hosts in the tls section need to explicitly match the host in the rules section.
crazylion lee

CertSimple | What web developers should know about HTTPS but probably don't. - 0 views

certsimple.com/...velopers-should-know-about-ssl

ssl security web encryption certificate https

shared by crazylion lee on 24 Nov 16 - No Cached
  • crazylion lee on 24 Nov 16
     
    "The most common questions we get from developers who already know their stuff"
crazylion lee

CertSimple | So you're making an RSA key for an HTTPS certificate. What key size do you... - 0 views

certsimple.com/...measuring-ssl-rsa-keys

ssl security encryption certificate https

shared by crazylion lee on 24 Nov 16 - No Cached
  • crazylion lee on 24 Nov 16
     
    "Or: why you probably don't want a 4096 bit RSA cert"
張 旭

certificate - What is a Pem file and how does it differ from other OpenSSL Generated Ke... - 0 views

serverfault.com/...her-openssl-generated-key-file

https security server apache nginx system

shared by 張 旭 on 22 Feb 17 - No Cached
  • Certificate Signing Request.
  • Some applications can generate these for submission to certificate-authorities
  • These get signed by the CA and a certificate is returned
  • ...15 more annotations...
  • The returned certificate is the public certificate (which includes the public key but not the private key), which itself can be in a couple of formats.
  • this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates
  • Privacy Enhanced Mail (PEM), a failed method for secure email but the container format it used lives on
  • This is a PEM formatted file containing just the private-key of a specific certificate and is merely a conventional name and not a standardized one.
  • The rights on these files are very important
  • /etc/ssl/private
  • OpenSSL can convert these to .pem
  • .cert .cer .crt A .pem (or rarely .der) formatted file with a different extension
  • there are four different ways to present certificates and their components
  • used preferentially by open-source software
  • It can have a variety of extensions (.pem, .key, .cer, .cert, more)
  • The parent format of PEM
  • a binary version of the base64-encoded PEM file.
  • PEM on it's own isn't a certificate, it's just a way of encoding data
  • X.509 certificates are one type of data that is commonly encoded using PEM.
張 旭

ssl - How to get .pem file from .key and .crt files? - Stack Overflow - 0 views

stackoverflow.com/...em-file-from-key-and-crt-files

https security server nginx apache ssl key

shared by 張 旭 on 22 Feb 17 - No Cached
  • openssl rsa -in server.key -text > private.pem openssl x509 -inform PEM -in server.crt > public.pem
  • A pem file contains the certificate and the private key.
張 旭

Let's Encrypt & Docker - Træfik - 0 views

docs.traefik.io/...docker-and-lets-encrypt

traefik docker networking proxy

shared by 張 旭 on 19 Sep 18 - No Cached
  • automatically discover any services on the Docker host and let Træfik reconfigure itself automatically when containers get created (or shut down) so HTTP traffic can be routed accordingly.
  • use Træfik as a layer-7 load balancer with SSL termination for a set of micro-services used to run a web application.
  • Docker containers can only communicate with each other over TCP when they share at least one network.
  • ...15 more annotations...
  • Docker under the hood creates IPTable rules so containers can't reach other containers unless you'd want to
  • Træfik can listen to Docker events and reconfigure its own internal configuration when containers are created (or shut down).
  • Enable the Docker provider and listen for container events on the Docker unix socket we've mounted earlier.
  • Enable automatic request and configuration of SSL certificates using Let's Encrypt. These certificates will be stored in the acme.json file, which you can back-up yourself and store off-premises.
  • there isn't a single container that has any published ports to the host -- everything is routed through Docker networks.
  • Thanks to Docker labels, we can tell Træfik how to create its internal routing configuration.
  • container labels and service labels
  • With the traefik.enable label, we tell Træfik to include this container in its internal configuration.
  • tell Træfik to use the web network to route HTTP traffic to this container.
  • Service labels allow managing many routes for the same container.
  • When both container labels and service labels are defined, container labels are just used as default values for missing service labels but no frontend/backend are going to be defined only with these labels.
  • In the example, two service names are defined : basic and admin. They allow creating two frontends and two backends.
  • Always specify the correct port where the container expects HTTP traffic using traefik.port label.
  • all containers that are placed in the same network as Træfik will automatically be reachable from the outside world
  • With the traefik.frontend.auth.basic label, it's possible for Træfik to provide a HTTP basic-auth challenge for the endpoints you provide the label for.
張 旭

SSL/TLS协议运行机制的概述 - 阮一峰的网络日志 - 0 views

www.ruanyifeng.com/...ssl_tls.html

ssh security server

shared by 張 旭 on 19 Jan 19 - No Cached
  • 客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
  • 互联网加密通信协议的历史，几乎与互联网一样长。
  • 将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
  • ...20 more annotations...
  • 每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。
  • "对话密钥"是对称加密，所以运算速度非常快
  • 服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
  • "对话密钥"
  • "握手阶段"（handshake）
  • 客户端向服务器端索要并验证公钥
  • "握手阶段"的所有通信都是明文的
  • 客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
  • 2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。
  • "客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
  • 验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
  • 从证书中取出服务器的公钥
  • 随后的信息都将用双方商定的加密方法和密钥发送
  • 前面发送的所有内容的hash值，用来供服务器校验。
  • 随机数用服务器公钥加密
  • 整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
  • 不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
  • 一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。
  • 服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。
  • 客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
  • 張 旭 on 19 Jan 19
     
    "客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。"
張 旭

CertSimple | An nginx config for 2017 - 0 views

certsimple.com/...nx-http2-load-balancing-config

nginx web server performance

shared by 張 旭 on 19 Mar 17 - No Cached
  • HAProxy can't terminate a HTTP/2 connection itself.
  • a server OS which includes OpenSSL 1.02 to have ALPN.
  • a new nginx (anything newer than 1.9.5 supports HTTP/2)
  • ...6 more annotations...
  • we like HTTPS/non-www since HTTPS is needed for current browsers and non-www is short.
  • visit the Mozilla TLS Generator to get the latest cipher suites and TLS versions
  • add the necessary headers for GeoIP and proper logging.
  • HTML5 SSE simpler than websockets
  • nginx -t
  • Scan your site with SSL Labs scan
crazylion lee

Certbot - 0 views

certbot.eff.org

Let's Encrypt letsencrypt ssl security https

shared by crazylion lee on 26 May 16 - No Cached
  • crazylion lee on 26 May 16
     
    "Let's Encrypt"
crazylion lee

Security/Server Side TLS - MozillaWiki - 0 views

wiki.mozilla.org/...Server_Side_TLS

ssl tls https

shared by crazylion lee on 24 Nov 14 - No Cached
  • crazylion lee on 24 Nov 14
     
    The goal of this document is to help operational teams with the configuration of TLS on servers. All Mozilla sites and deployment should follow the recommendations below. The Operations Security (OpSec) team maintains this document as a reference guide to navigate the TLS landscape. It contains information on TLS protocols, known issues and vulnerabilities, configuration examples and testing tools. Changes are reviewed and merged by the OpSec team, and broadcasted to the various Operational teams.
1 - 20 of 28 Next ›
Showing 20▼ items per page