Survivalmonkey.com is now fully SSL TLS encrypted

Discussion in 'Site Announcements' started by melbo, Jun 25, 2014.


  1. melbo

    melbo Hunter Gatherer Administrator Founding Member

    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.

    eMail.

    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
    secure-ssl-connection.
    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

    secure-connection-illustration.

    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.
    PositiveSSL.

    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):
     

    Attached Files:

    Last edited: Jun 26, 2014
  2. Motomom34

    Motomom34 Moderator Moderator Site Supporter++

    I have a question. Someone was working on the home next door to us. He asked us if he could hop onto our wi-fi cause he was going to be there for a few days. Did he have access to our computers or just our wi-fi?
     
  3. melbo

    melbo Hunter Gatherer Administrator Founding Member

    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
     
    Last edited: Jun 26, 2014
    chelloveck, Motomom34 and Brokor like this.
  4. BTPost

    BTPost Old Fart Snow Monkey Moderator

    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. .....
     
    Motomom34 likes this.
  5. Motomom34

    Motomom34 Moderator Moderator Site Supporter++

    Thank you- after reading that I worried. Instead of being neighborly I was being naive and stupid. I have learned look for the lock if I really want to be safe.
     
  6. melbo

    melbo Hunter Gatherer Administrator Founding Member

    chelloveck, BTPost and Brokor like this.
  7. melbo

    melbo Hunter Gatherer Administrator Founding Member

    Motomom34, VisuTrac and BTPost like this.
  8. melbo

    melbo Hunter Gatherer Administrator Founding Member

    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
    [​IMG]
    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


    [​IMG]
    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


    [​IMG]
    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
    [​IMG]
    Protocols
    TLS 1.2 Yes
    TLS 1.1 Yes
    TLS 1.0 Yes
    SSL 3 Yes
    SSL 2 No


    [​IMG]
    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


    [​IMG]
    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).


    [​IMG]
    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
     
    VisuTrac likes this.
  9. Motomom34

    Motomom34 Moderator Moderator Site Supporter++

    Oh my! The bank I do e-banking on has a B & Warning: Inconsistent server configuration.

    Thanks Melbo. I didn't realize.
     
  10. melbo

    melbo Hunter Gatherer Administrator Founding Member

    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?
     
    Last edited: Jan 26, 2015
  11. BTPost

    BTPost Old Fart Snow Monkey Moderator

    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. .....
     
    Dont and chelloveck like this.
  1. Yard Dart
  2. GhostX
  3. Yard Dart
  4. Salted Weapon
  5. DarkLight
  6. Motomom34
  7. lonewolf88
  8. stg58
  9. Garand69
  10. chelloveck
  11. DLConcepts
  12. stg58
  13. DarkLight
  14. DarkLight
  15. DarkLight
  16. melbo
  17. Ganado
  18. Yard Dart
  19. Ganado
  20. Motomom34
survivalmonkey SSL seal        survivalmonkey.com warrant canary
17282WuJHksJ9798f34razfKbPATqTq9E7