summaryrefslogtreecommitdiff
path: root/pages/docs
diff options
context:
space:
mode:
Diffstat (limited to 'pages/docs')
-rw-r--r--pages/docs/design/nicknym-draft.md4
-rw-r--r--pages/docs/design/nicknym.md2
-rw-r--r--pages/docs/platform/troubleshooting/tests.md2
-rw-r--r--pages/docs/platform/tutorials/quick-start.md2
-rw-r--r--pages/docs/platform/tutorials/single-node-email.md2
-rw-r--r--pages/docs/tech/hard-problems/pt.md2
6 files changed, 7 insertions, 7 deletions
diff --git a/pages/docs/design/nicknym-draft.md b/pages/docs/design/nicknym-draft.md
index 9398a9f..e96ce96 100644
--- a/pages/docs/design/nicknym-draft.md
+++ b/pages/docs/design/nicknym-draft.md
@@ -85,7 +85,7 @@ There are a number of established methods for binding identifier to key:
* [X.509 Certificate Authority System](https://en.wikipedia.org/wiki/X.509)
* Trust on First Use (TOFU)
* Mail-back Verification
-* [Web of Trust (WOT)](http://en.wikipedia.org/wiki/Web_of_trust)
+* [Web of Trust (WOT)](https://en.wikipedia.org/wiki/Web_of_trust)
* [DNSSEC](https://en.wikipedia.org/wiki/Dnssec)
* [Shared Secret](https://en.wikipedia.org/wiki/Socialist_millionaire)
* [Network Perspective](http://convergence.io/)
@@ -156,7 +156,7 @@ For a long discussion of the simple thing, see [messaging list](https://moderncr
**WebID and Mozilla Persona**
-What about [WebID](http://www.w3.org/wiki/WebID) or [Mozilla Persona](https://www.mozilla.org/en-US/persona/)? These are both interesting standards for cryptographically proving identify, so why do we need something new?
+What about [WebID](https://www.w3.org/wiki/WebID) or [Mozilla Persona](https://www.mozilla.org/en-US/persona/)? These are both interesting standards for cryptographically proving identify, so why do we need something new?
These protocols, and the poorly conceived OpenID Connect, are designed to address a fundamentally different problem: authenticating a user to a website. The problem of authenticating users to one another requires a different architecture entirely. There are some similarities, however, and in the long run a Nicknym provider could also be a WebID and Mozilla Persona provider.
diff --git a/pages/docs/design/nicknym.md b/pages/docs/design/nicknym.md
index 3f94875..cb638ab 100644
--- a/pages/docs/design/nicknym.md
+++ b/pages/docs/design/nicknym.md
@@ -51,7 +51,7 @@ There are a number of established methods for binding identifier to key:
* [X.509 Certificate Authority System](https://en.wikipedia.org/wiki/X.509)
* Trust on First Use (TOFU)
* Mail-back Verification
-* [Web of Trust (WOT)](http://en.wikipedia.org/wiki/Web_of_trust)
+* [Web of Trust (WOT)](https://en.wikipedia.org/wiki/Web_of_trust)
* [DNSSEC](https://en.wikipedia.org/wiki/Dnssec)
* [Shared Secret](https://en.wikipedia.org/wiki/Socialist_millionaire)
* [Network Perspective](http://convergence.io/)
diff --git a/pages/docs/platform/troubleshooting/tests.md b/pages/docs/platform/troubleshooting/tests.md
index 418f6c9..383fe7b 100644
--- a/pages/docs/platform/troubleshooting/tests.md
+++ b/pages/docs/platform/troubleshooting/tests.md
@@ -50,7 +50,7 @@ In order to set up a monitoring node, you simply add a `monitor` service tag to
After deploying, this node will regularly poll every node to ask for the status of various health checks. These health checks include the checks run with `leap test`, plus many others.
-We use [Nagios](http://www.nagios.org/) together with [Check MK agent](https://en.wikipedia.org/wiki/Check_MK) for running checks on remote hosts.
+We use [Nagios](https://www.nagios.org/) together with [Check MK agent](https://en.wikipedia.org/wiki/Check_MK) for running checks on remote hosts.
One nagios installation will monitor all nodes in all your environments. You can log into the monitoring web interface via [https://DOMAIN/nagios3/](https://DOMAIN/nagios3/). The username is `nagiosadmin` and the password is found in the secrets.json file in your provider directory.
Nagios will send out mails to the `contacts` address provided in `provider.json`.
diff --git a/pages/docs/platform/tutorials/quick-start.md b/pages/docs/platform/tutorials/quick-start.md
index a92cc9d..e9e9172 100644
--- a/pages/docs/platform/tutorials/quick-start.md
+++ b/pages/docs/platform/tutorials/quick-start.md
@@ -267,7 +267,7 @@ If you prefer, you can initalize each node, one at a time:
Deploy the LEAP platform to the nodes
--------------------
-Now you should deploy the platform recipes to the nodes. [Deployment can take a while to run](http://xkcd.com/303/), especially on the first run, as it needs to update the packages on the new machine.
+Now you should deploy the platform recipes to the nodes. [Deployment can take a while to run](https://xkcd.com/303/), especially on the first run, as it needs to update the packages on the new machine.
*Important notes:* currently nodes must be deployed in a certain order. The underlying couch database node(s) must be deployed first, and then all other nodes.
diff --git a/pages/docs/platform/tutorials/single-node-email.md b/pages/docs/platform/tutorials/single-node-email.md
index 872d1da..a126938 100644
--- a/pages/docs/platform/tutorials/single-node-email.md
+++ b/pages/docs/platform/tutorials/single-node-email.md
@@ -164,7 +164,7 @@ This will initialize the node "node1". When `leap node init` is run, you will be
Deploy the LEAP platform to the nodes
--------------------
-Now you should deploy the platform recipes to the node. [Deployment can take a while to run](http://xkcd.com/303/), especially on the first run, as it needs to update the packages on the new machine.
+Now you should deploy the platform recipes to the node. [Deployment can take a while to run](https://xkcd.com/303/), especially on the first run, as it needs to update the packages on the new machine.
$ leap deploy
diff --git a/pages/docs/tech/hard-problems/pt.md b/pages/docs/tech/hard-problems/pt.md
index 50c0541..7bb0637 100644
--- a/pages/docs/tech/hard-problems/pt.md
+++ b/pages/docs/tech/hard-problems/pt.md
@@ -70,7 +70,7 @@ Esta abordagem é potencialmente eficaz contra os observadores externos na rede,
No longo prazo, pretendemos trabalhar com outros grupos para criar novos padrões de protocolo de criptografia que podem ser tanto assíncronos quanto permitir o sigilo futuro:
- * [Extensões para sigilo futuro para o OpenPGP](http://tools.ietf.org/html/draft-brown-pgp-pfs-03).
+ * [Extensões para sigilo futuro para o OpenPGP](https://tools.ietf.org/html/draft-brown-pgp-pfs-03).
* [Handshake Diffie-Hellman triplo com curvas elípticas](https://whispersystems.org/blog/simplifying-otr-deniability/).
### Problema do grupo