Survivalmonkey.com is now fully SSL TLS encrypted

You may have noticed that all SM urls are now displaying as https:// in your browser. Depending on the browser, you may see a little lock or green bar to the far left. This means that the page is encrypted from your machine to the server, maintaining your privacy as the information (both ways) hop from many machines in-between.

In short, your ISP, that 13 old neighbor kid, the guy next to you on public wifi at the coffee shop and many other machines between you and this server cannot read your PMs or pinpoint anything else that you are reading or posting as @survivalmonkey_User. You have a much better shot at anonymity than before we were secured with SSL.



Read on for the longer version if you wish.

What is SSL?
SSL (Secure Sockets Layer) is a standard technology behind establishing an encrypted connection between a web server (host) and a web browser (client). This connection between the two makes sure that all the data passed between them remain private and intrinsic. SSL is an industry standard and is used by millions of websites to protect their online transactions with their customers. If you have ever visited a website using the https:// in the address bar you were creating a secure connection via SSL. SSL helps in establishing trust with your customers.

Understanding how the SSL connection protects your data

Using an SSL certificate creates an encrypted connection between the user's web browser and the web server. This means that any data transmitted between the web server and the web browser can not be read without first being decrypted. This protects the data from being spied upon by someone else on the internet because they will not be able to understand the encrypted data.

How the encrypted connection is established



There a few basic steps that occur when you attempt to establish secure connection. Here's a summary of the steps:

1. You type in or select the secure URL (e.g. "Survival Monkey Forums")
2. The web server receives your request and then submits a reply that attempts to establish trusted connection between the web browser and the web server - also called the "SSL handshake."
3. After the SSL certificate is verified through the SSL handshake, the data transferred between the web server and web browser is encrypted to keep it private and secure.

How to tell if a site is using SSL
While the details of the SSL protocol are not displayed to the visitor, most browsers will display a lock or some other form of identification in the address bar. This will indicate if you are currently protected by an SSL encrypted session. If you would like the details of the SSL certificate you can simply click on the lock.

What does the SSL mean to visitors?
Most SSL Certificates contain the domain name, company name, address, city, state, and country. It also contains an expiration date of the certificate and the details of the Certificate Authority (the company who issued the SSL). When a browser attempts to establish an SSL connection to a website it checks to make sure the certificate is not expired, has been issued by a trusted authority, and is being used for the correct website. If any of these checks fails your web browser will display a warning letting the user know that the site is not secured by SSL.


tl;dr You don't have to understand how or why, just know that we're doing everything we can to protect your privacy while at SM.

The valid SM SSL certificate was revoked and reissued after the HeartBleed vulnerabilities were discovered.

Code:

Certificate Fingerprints
SHA1:    9F AA 8C 08 E3 B9 A2 70 33 33 E7 DC 2C 67 E4 26 C8 6E 7D F1
MD5:    3C 5E 43 E2 18 58 B9 0D 22 F5 89 1F B1 AB 47 47

Code:

Public Key Info
Key Algorithm:    RSA
Key Parameters:    05 00
Key Size:    4096
Key SHA1 Fingerprint:    18 15 54 A9 43 68 38 0F 76 6F 82 A6 66 49 DF 0E 43 8F BA B1
Public Key:    30 82 02 0A 02 82 02 01 00 CB 09 E6 42 90 AD 03 9C 48 20 CC 68 9D BD 75 D5 96 3B 9F F6 70 0D 51 2A 5D 4B 38 DF 89 36 9C E0 9A 3B F5 3B 4A C8 E7 74 85 D9 F8 08 99 E1 3E FC 04 71 E2 EF 20 A5 12 82 A9 DA 55 ED AA 61 EF 9E 20 F2 69 A4 7F 52 24 E4 DF 57 43 3D 0E 84 CF 77 83 A4 33 75 62 5A 89 B4 07 AA AA E2 28 FA 85 AA 3C 28 16 02 FC D9 22 45 F2 CE C6 12 CE 60 08 2F 61 1D 9F 1A 1F DC BB 7F 31 F2 0E D8 C9 25 53 EF 27 F2 AF 0A 5F CB 8E B4 03 E9 39 F1 46 14 35 9F 0F E8 5C D1 10 5E 0F 4E E1 2F F5 F2 89 0C 24 6E 36 BC E0 B1 F5 C6 FA E9 B2 BB 2A F2 84 90 1C 4F 4A DC A6 87 26 25 BA D1 9B 99 CD 87 AB E4 CF 85 13 C8 35 3C E7 D6 D5 4C 31 28 B1 4A 2C B0 11 BF 9D 9E F1 E4 95 78 89 47 9B C3 5F D8 51 76 4B 4B 7E C5 22 D1 40 15 02 C1 59 DA AF C4 76 C1 A3 2E 8B D1 50 70 EA D9 1F 69 56 0E 72 36 17 30 4B 86 1B C2 8C 66 EE 61 3A C8 3B F6 73 10 0C 2B 08 3E 4C 4D 0A 50 CD F3 41 7B 20 03 51 F1 D4 47 3C D9 9F 69 9C 32 84 05 C5 50 0A 61 1A FE 45 48 A4 75 B5 6A AB 50 FB 28 1A F8 46 97 06 72 CE E7 40 EC 75 E3 74 9F AD D6 80 C6 F7 C5 44 0B 05 BD 30 1B CD 62 A7 83 23 8F C6 59 29 7C 59 CE DA EB EE 73 BC DE EB 04 81 CD 2E 12 D5 0A F5 E5 7D DC E0 1E 59 50 7E 23 E8 BB 7D 83 BB E2 5E 83 16 82 09 30 BE 02 90 62 9B 1B 58 DB 5D 32 60 90 53 A6 76 6D 03 D6 E9 C9 D9 67 AA 28 47 A1 75 C1 10 C5 5F C4 13 BF C8 8F 5C 17 C8 A7 D5 15 8C BB 8E BE 8E D5 FF B5 03 29 51 44 93 1E 54 64 54 51 51 23 F7 B1 7D 30 48 CB 12 BC 67 6F A4 7B C7 22 AE 9A 12 94 79 6E 56 7A 5D E9 16 FD D9 87 D3 E0 5C EB 98 D4 27 96 7B 9F 14 FE 3A 18 48 D2 D2 0B A0 AC 4E 12 60 40 B5 F9 FF 0A 85 40 7A AD 1C 89 EB D3 B7 A3 02 03 01 00 01

Why are we doing all of this extra security stuff? We attempt by all means to ensure the privacy of our members.

SSL Certificate details (public):

 

A smart cracker with a few free programs can possibly get into your computers and read any traffic from your systems if on your wifi (network).
Most people have no malicious intentions but it is possible.

A couple of good reads -
A Guide to Sniffing Out Passwords and Cookies (and How to Protect Yourself Against It)
Here's what an eavesdropper sees when you use an unsecured Wi-Fi hotspot | PCWorld
Firesheep - Wikipedia, the free encyclopedia

None of your SM traffic could be read/seen in the above cases now that we are running with encryption.
@seth_test

 

Now that the SSL has been patched, for the HeartBleed Issue, Melbo is correct, in that your Monkey connection is encrypted in both directions, and a "Man in the Middle" attack will fail. This does NOT protect you, when you visit other sites, if they are not SSL Encrypted, or when you are sending eMail, skype or other Non-SSL connections. .....

 

We are now also HSTS (HTTPS Strict Transport Security) compliant.
HTTP Strict Transport Security - Wikipedia, the free encyclopedia

 

you can test SM here at Qualsys SSL Labs: Qualys SSL Labs - Projects / SSL Server Test / survivalmonkey.com
It takes a couple of minutes but you'll be able to see we currently score an A+ which is, oddly enough, much stronger than 3 random banks I checked

 

Full Report:

SSL Report: survivalmonkey.com (206.123.114.178)
Assessed on: Tue Jul 01 00:17:10 UTC 2014 |

Summary
Overall Rating
A+

Documentation: SSL/TLS Deployment Best Practices, SSL Server Rating Guide, and OpenSSL Cookbook.
This server supports HTTP Strict Transport Security with long duration. Grade set to A+. MORE INFO »
This server is not vulnerable to the Heartbleed attack.
Experimental: This server is not vulnerable to the OpenSSL CCS vulnerability (CVE-2014-0224).


Authentication

Server Key and Certificate #1
Common names Survival Monkey Forums
Alternative names Survival Monkey Forums survivalmonkey.com
Prefix handling Both (with and without WWW)
Valid from Wed Feb 12 00:00:00 UTC 2014
Valid until Mon Feb 11 23:59:59 UTC 2019 (expires in 4 years and 7 months)
Key RSA 4096 bits
Weak key (Debian) No
Issuer COMODO RSA Domain Validation Secure Server CA
Signature algorithm SHA256withRSA
Extended Validation No
Revocation information CRL, OCSP
Revocation status Good (not revoked)
Trusted Yes



Additional Certificates (if supplied)
Certificates provided 4 (5665 bytes)
Chain issues Contains anchor
#2
Subject COMODO RSA Domain Validation Secure Server CA
SHA1: 339cdd57cfd5b141169b615ff31428782d1da639
Valid until Sun Feb 11 23:59:59 UTC 2029 (expires in 14 years and 7 months)
Key RSA 2048 bits
Issuer COMODO RSA Certification Authority
Signature algorithm SHA384withRSA
#3
Subject COMODO RSA Certification Authority
SHA1: f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0
Valid until Sat May 30 10:48:38 UTC 2020 (expires in 5 years and 10 months)
Key RSA 4096 bits
Issuer AddTrust External CA Root
Signature algorithm SHA384withRSA
#4
Subject AddTrust External CA Root In trust store
SHA1: 02faf3e291435468607857694df5e45b68851868
Valid until Sat May 30 10:48:38 UTC 2020 (expires in 5 years and 10 months)
Key RSA 2048 bits
Issuer AddTrust External CA Root Self-signed
Signature algorithm SHA1withRSA



Certification Paths
Path #1: Trusted
1 Sent by server Survival Monkey Forums
SHA1: 9faa8c08e3b9a2703333e7dc2c67e426c86e7df1
RSA 4096 bits / SHA256withRSA
2 Sent by server COMODO RSA Domain Validation Secure Server CA
SHA1: 339cdd57cfd5b141169b615ff31428782d1da639
RSA 2048 bits / SHA384withRSA
3 Sent by server COMODO RSA Certification Authority
SHA1: f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0
RSA 4096 bits / SHA384withRSA
4 Sent by server
In trust store AddTrust External CA Root
SHA1: 02faf3e291435468607857694df5e45b68851868
RSA 2048 bits / SHA1withRSA



Configuration

Protocols
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 Yes
SSL 2 No



Cipher Suites (SSL 3+ suites in server-preferred order, then SSL 2 suites where used)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 112
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 4096 bits (p: 512, g: 1, Ys: 512) FS 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128



Handshake Simulation
Android 2.3.7 No SNI 2 TLS 1.0 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) FS 128
Android 4.0.4 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Android 4.1.1 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Android 4.2.2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Android 4.3 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128
BingBot Dec 2013 No SNI 2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
BingPreview Dec 2013 TLS 1.0 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) FS 128
Chrome 34 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128
Firefox 24.2.0 ESR / Win 7 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Firefox 29 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128
Googlebot Oct 2013 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
IE 6 / XP No FS 1 No SNI 2 SSL 3 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) No FS 112
IE 7 / Vista TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
IE 8 / XP No FS 1 No SNI 2 TLS 1.0 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) No FS 112
IE 8-10 / Win 7 R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
IE 11 / Win 7 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) FS 128
IE 11 / Win 8.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) FS 128
IE Mobile 10 / Win Phone 8.0 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
IE Mobile 11 / Win Phone 8.1 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) FS 128
Java 6u45 No SNI 2 Client does not support DH parameters > 1024 bits Fail3
Java 7u25 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Java 8b132 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128
OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) FS 128
OpenSSL 1.0.1e TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128
Safari 5.1.9 / OS X 10.6.8 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Safari 6 / iOS 6.0.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) FS 128
Safari 7 / iOS 7.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) FS 128
Safari 6.0.4 / OS X 10.8.4 R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
Safari 7 / OS X 10.9 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) FS 128
Yahoo Slurp Oct 2013 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
YandexBot May 2014 TLS 1.0 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) FS 128
(1) Clients that do not support Forward Secrecy (FS) are excluded when determining support for it.
(2) No support for virtual SSL hosting (SNI). Connects to the default site if the server uses SNI.
(3) Only first connection attempt simulated. Browsers tend to retry with a lower protocol version.
(R) Denotes a reference browser or client, with which we expect better effective security.
(All) We use defaults, but some platforms do not use their best protocols and features (e.g., Java 6 & 7, older IE).



Protocol Details
Secure Renegotiation Supported
Secure Client-Initiated Renegotiation No
Insecure Client-Initiated Renegotiation No
BEAST attack Not mitigated server-side (more info) SSL 3: 0xc013, TLS 1.0: 0xc013
TLS compression No
RC4 No
Heartbeat (extension) Yes
Heartbleed (vulnerability) No (more info)
OpenSSL CCS vuln. (CVE-2014-0224) No
Forward Secrecy Yes (with most browsers) ROBUST (more info)
Next Protocol Negotiation No
Session resumption (caching) Yes
Session resumption (tickets) Yes
OCSP stapling No
Strict Transport Security (HSTS) Yes max-age=31536000
Long handshake intolerance No
TLS extension intolerance No
TLS version intolerance TLS 2.98
SSL 2 handshake compatibility Yes

 

Here's another example from surespot | encrypted chat messenger | 100% open source , an encrypted IM system. They are speaking of email and text but it is no different than a website where you post and read data on.



Traditional IM (OTT), SMS, etc. communications send messages in "plain text". This means that the information is sent without anything done to protect the information from being read by anyone else. It is akin to sending a postcard.

Imagine you are on vacation in Italy, Florence to be precise, and you send a postcard to your sister in London. As the postcard travels anyone that touches it can read it. Typically you do not send information like a credit card number or your pin number or an intimate thought using the postcard format. Today this is what sending an email or a text message or an instant message or a picture is like. The message is the postcard which travels along many hops until it reaches its destination. At every one of these "hops" the message could potentially be read.

For example you, are reading an email at Starbucks. To read this email the information travels from the server (gmail) through their (Google's) ISP, to Starbuck's ISP, to the Starbucks location you are at. At any one of these points the email can be read. To illustrate this we can run the traceroute command which shows the hops your data is taking to reach its destination.

for example the traceroute from my house to mail.google.com looks like this:

• [adam@monkey ~]$ traceroute mail.google.com
• traceroute to mail.google.com (16.123.225.123), 30 hops max, 60 byte packets
• 1 DD-WRT.mugello (192.168.10.1) 0.506 ms 0.598 ms 0.794 ms
• 2 24.9.100.1 (24.9.100.1) 16.723 ms 17.837 ms 32.677 ms
• 3 ge-1-39-sr01.summit.co.denver.comcast.net (68.85.220.81) 17.710 ms 17.711 ms 17.828 ms
• 4 te-0-3-0-5-ar02.denver.co.denver.comcast.net (68.86.179.13) 21.140 ms 22.087 ms 22.145 ms
• 5 pos-0-7-0-0-ar02.aurora.co.denver.comcast.net (68.86.128.246) 25.333 ms 25.334 ms 25.448 ms
• 6 he-3-4-0-0-cr01.denver.co.ibone.comcast.net (68.86.90.149) 24.116 ms 20.657 ms 20.689 ms
• 7 * * *
• 8 173.167.57.206 (173.167.57.206) 17.512 ms 18.328 ms 18.402 ms
• 9 72.14.234.57 (72.14.234.57) 16.190 ms 16.218 ms 16.160 ms
• 10 209.85.251.111 (209.85.251.111) 16.674 ms 20.817 ms 21.715 ms
• 11 den03s06-in-f21.1e100.net (74.125.225.213) 17.238 ms 18.200 ms 18.152 ms

We can see that to get to Google's server at mail.google.com, the data is being routed through at least 11 hops, anyone of which could have a chance to intercept the information. Now if you controlled the routing and could make the data on your network always pass through a certain one of these hops, you could monitor all of the “plain text” data being sent on your network. Not exactly "secure".

so how do we get around this?

You may have seen at times when you used your web browser that the URL was pointing to https:// instead of http:// and there was an associated padlock icon or similar. This indicates that the connection is being made using SSL or Secure Sockets Layer. This means that the connection from your web browser to the server is encrypting the information. "Incryptography, encryption is the process of encoding messages (or information) in such a way that eavesdroppers or hackers cannot read it, but that authorized parties can." (Wikipedia). So applying this to our mail.google.com traceroute above, this means that only hop 1 (my computer) and hop 11 (Google's server) can see the information, all that hops 2-10 can see is encrypted HTTPS traffic. This is great! There is however still a problem. We have logged onto https://mail.google.com presumably to send an email, which in this case contains a credit card number. So we send the email to someone at Hotmail, cherie. Now the email which is in plain text is sent from Google's server to the Hotmail server and eventually to the recipient's device, taking a multi-hopped path much like the traceroute above. At this point we no longer have control over how the message is secured. Is Google using SSL to transmit the message to Hotmail? Probably. Is the message downloaded from Hotmail to the recipient's device in a secure manner? Maybe, but how can we be sure? Now extrapolate this example to any information you send on the internet. What is happening to your data when it is on the server or in transit in plain text? How could anyone possibly know? How secure is the server at protecting your plain text data from hackers? What are the guardians of your data doing with your data?

 

This is where P2P Encrypted Messaging is going to save you.... P2P = (Peer to Peer) Which means that your message goes from Your Device, directly to the other Device, on the other end of the Route, and only you two, have the Encryption Keys to generate, and read the Messages. CryptoCat is such a P2P Encrypted Messaging System, that uses an Encrypted Server in the middle and the Server does NOT have the Encryption Keys to decode the Message. GPG can do this for eMail, but is not an easy thing to learn to use in some OS Systems. BitMessage is another P2P Encrypted Messaging System, that requires No "Server" as such but does pass your Encrypted Message thru other peoples BitMessage Clients, although they do NOT have the Encryption Keys to read the Message, but only to pass it along to the final Destination, which DOES have the Encryption Keys, to decode the Message. .....

 

Just a further note here: Apples FaceTime is a P2P End to End Encrypted App… Only the two end devices have the Keysets to encrypt and decrypt the information… also each individual time you use the App and make a connection, you are using a new One Time Use Only Encryption KeySet, that is discarted at the completion of the connection…