Sean

I'm on a Spectrum 100 Mbps down load, 10 Mbps upload plan. I replaced my 100 Mbps wired router with a used $57 5th gen Apple AirPort Extreme Base Station (gigabit Ethernet)
 
my speeds improved from 80 Mbps average upload to about 116 Mbps. The first pic shows the before and after plot. The second pic is the latest average.
 
the 3rd pic is one test plot with the old router. 4th pic is one test with plot the new router. 
 
TestMy helped me identify the potential limitation of the 100 Mbps wired router (it was trying very hard), and testing here documents the improvement. Great site.

So I started nmap up, ran some scans (I'm sure @CA3LE won't mind me running some penetration tests against his server) on the SSL ports, and I couldn't find RC4 on the list of ciphers, at all, but then I did on an SMTPS (465) port, but you shouldn't be affected by that.
 
So I got curious, and researched further, and you said it happens about every 10th website, so I have a few follow up questions:
 
1. Are you using Wireless?
   a. If so, are you using WEP? Apparently RC4 was used in the WEP security standard (which has been an insecurity standard for years now).
2. Are you certain there is no MITM attack against you?
 
For those interested, here's the result of my nmap scan:
 
Elliotts-iMac:~ elliottbrown$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.testmy.net Starting Nmap 7.50 ( https://nmap.org ) at 2017-07-20 18:29 EDT Nmap scan report for www.testmy.net (64.111.22.10) Host is up (0.088s latency). rDNS record for 64.111.22.10: testmy.net PORT STATE SERVICE 443/tcp open https | ssl-cert: Subject: commonName=testmy.net | Subject Alternative Name: DNS:testmy.net | Issuer: commonName=Let's Encrypt Authority X3/organizationName=Let's Encrypt/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2017-07-06T06:00:00 | Not valid after: 2017-10-04T06:00:00 | MD5: 415f 2e2b ee78 0642 6813 4e47 743b 9831 |_SHA-1: ecac a111 d818 d982 1039 acea 2fe4 9b6c c975 ca43 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server |_ least strength: A 465/tcp open smtps | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | SSLv3: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | CBC-mode cipher in SSLv3 (CVE-2014-3566) | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA256 - F | TLS_DH_anon_WITH_AES_128_GCM_SHA256 - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA256 - F | TLS_DH_anon_WITH_AES_256_GCM_SHA384 - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: F 993/tcp open imaps | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: D 995/tcp open pop3s | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: D Nmap done: 1 IP address (1 host up) scanned in 27.86 seconds Elliotts-iMac:~ elliottbrown$  
The letter after the cipher is a letter from A-F, indicating grade of the cipher (A being best, F being worst), you'll notice there are a few RC4 ciphers under the 465, 993 and 995 ports (graded F appropriately), but all of the TLS ciphers are grade A.
 
The lowest cipher strength (according to nmap) on https://www.testmy.net/ is a grade A, so Chrome should definitely not be flagging this site. (In fact, based on this information, testmy.net would refuse an RC4 cipher connection, period.)
 
You definitely have a different issue going on, and I'm curious as to what that is.
 
Thanks,
EBrown

Hah, forgot to post this here. Yeah, they asked me about it on Twitter a week or so ago.
 
It's an interesting topic, we're discussing things that should never have to be worried about, no one should fear that their ISP can censor what they can see based on the ISP's own political motives. (Hell, just look at the Comcast v. Netflix issue from a couple years ago: Netflix traffic was throttled to unbelievable slow speeds as a result of Comcast wanting to extort them for money.)
 
Personally, I am anti-government regulation, but in this case it's a necessity.
 
One of the arguments I have recently heard in favor of revocation of the net–neutrality law was:
 
 
This is a false premise, if the ISP's customers want traffic from that source, the ISP should not be throttling it in either direction. If your customers want to watch Netflix all day, you don't get to make additional profit off of that. The customer already pays for a broadband connection, it is the ISP's job to deliver that broadband service in an unbiased manner.
 
Thanks,
EBrown

Our very own @nanobot or EBrown has been interviewed by the BBC on Net Neutrality, here is what he had to say.
 
 
Very nicely worded Elliot
 
The full story can be found here
 
To get more information as to the issues regarding net neutrality, visit or even join the EFF (Electronic Frontier Foundation)

One possibility could be an issue with the Internet Security / antivirus software. 
 
Some Internet Security products intercept HTTPS connections to scan traffic in much the same way they scan regular HTTP traffic.  In order to intercept HTTPS, they need to act as a 'man in the middle'.  As certificates are designed to prevent man in the middle attacks, the security package installs its own root certificate in each browser. 
 
When the security software decrypts traffic to scan it, it re-encrypts the traffic using its own certificate, which the browser will trust due to the security software discreetly installing the root certificate earlier. 
 
What I suspect is that Chrome (and in turn Slimjet) may have an older certificate that uses a less secure cypher.  In this case when the security software intercepts and re-encrypts HTTPS traffic, Chrome will try to authenticate that certificate against the obsolete root certificate and present the error. 
 
What I suggest trying is temporarily disable the web filtering (or the antivirus software altogether) and try accessing an affected site in Chrome.  If it now loads fine (i.e. Chrome sees the proper certificate instead of the security software's one), then I recommend uninstalling and reinstalling the antivirus package. 

No problem - Multithreaded test with UK server now working fine here...
 

 
This now brings up the expected ~3.9Mbps for my DSL connection.
 

I just want to check if anyone had a chance to look at this issue over the past month.
 
From a quick check, the UK server with the multithread test is still picking unresolvable hosts in each test:
 

 
The Frankfurt (Germany) one seems to be fine, i.e. not one 502 error after running multiple tests:
 

I personally see the other test guys as bloated fluffy and sprinkled with glitter to make your speed look good.
TMN currently is my top source for actual answers.
 
So trying Frankfurt servers with Ookla and getting average 300+, to me is false and completely not possible. I LIVE IN CANADA. My speed SHOULD be lower if I am testing against Europe. I expect that at least some latency or speed drop.
 
Have you attempted to connect via Ethernet and speed test again this way? Do the results change? Are you getting completely different numbers altogether?
 
Side note:
Just to clarify, as it may be called something different here or maybe I am not understanding.
is WLAN sticks just another name for USB WiFi Adaptors for laptops / desktops that don't have network card with WiFi capability built in or is WLAN sticks the 3G/4G Cellular Network USB sticks? (I assume the former, hence why I suggested Ethernet test, since you would have a modem/router hopefully nearby)

I have the same experience with 4G (cellular LTE) based broadband connections, such as when positioning a directional antenna.  When the network is quiet (e.g. early on a weekend morning), there can be a large variation between what SpeedTest and TestMy reports if the antenna is not aimed correctly.  Once the antenna is carefully aimed, the TestMy results climb up towards what Speedtest reports.  It's similar also if there are swaying branches in line of sight as Speedtest will again ignore the brief dips as if the bandwidth is sustained. 
 
If Speedtest measured road trip speeds, their speed test methodology would eliminate traffic lights, construction zones, slow vehicles, busy junctions and everything else that accounted for the slowest 30% of the journey.
 
If TestMy measured road trips, it would run a stopwatch from the moment of departure to the moment of arrival.
 
Of course like the Speedtest fanatics, there would be those that would argue the same for road trip measurements - "What if that construction zone was not there, those traffic lights were green, no accident on the route, ..." 

I get the impression that the IP address is the victim of a DDoS attack, where Verizon has decided to null route all incoming traffic sent to it on most or all its routers to minimise traffic on its network from the attack. 
If this is the case, the next hop after your home router would be one of their routers (assuming your ISP is Verizon), hence no reply after your router.  For the Level3 site traceroute, the third hop shown in your screenshot is at Verizon, so the next hop inside their network would also be one of their routers probably configured to null route that IP address.
A few more tests worth trying would be a TCP traceroute and a UDP traceroute.  If both give a similar result, then it's most likely that IP address is null routed rather than just ICMP filtering to block a trace route to it.

Hi
 
By means of an update, I am now obtaining approx. 30Mbps download using 4G from EE.
 
I have a further question ....
 
The TP-LINK MR200 router I am using is reporting a 50% signal strength - if I use an antenna to try to increase the signal strength, is it likely I would I obtain a further increase in download speeds and, if so, by approx. how much ?
 
Thanks in advance.
 
 

Great analogy!
 
For those who'd argue "What if that construction zone was not there, those traffic lights were green, no accident on the route, ..." 
 
Do you want to know how long it might take if everything were perfect... or would you rather know the true amount of time it will take?  Who cares about the time it would take if there were no variables, it's irrelevant if it can never be achieved in the real world.  I don't know about you but if I set off on a road trip and Google Maps said, "6 hours" and then it ends up taking 24 hours because of stop lights, construction and speed limits (all known before)... I'd be really pissed.  I'd rather be told the truth with all things considered so that I can plan accordingly.
 
 

I have the same experience with 4G (cellular LTE) based broadband connections, such as when positioning a directional antenna.  When the network is quiet (e.g. early on a weekend morning), there can be a large variation between what SpeedTest and TestMy reports if the antenna is not aimed correctly.  Once the antenna is carefully aimed, the TestMy results climb up towards what Speedtest reports.  It's similar also if there are swaying branches in line of sight as Speedtest will again ignore the brief dips as if the bandwidth is sustained. 
 
If Speedtest measured road trip speeds, their speed test methodology would eliminate traffic lights, construction zones, slow vehicles, busy junctions and everything else that accounted for the slowest 30% of the journey.
 
If TestMy measured road trips, it would run a stopwatch from the moment of departure to the moment of arrival.
 
Of course like the Speedtest fanatics, there would be those that would argue the same for road trip measurements - "What if that construction zone was not there, those traffic lights were green, no accident on the route, ..." 

Happy New Year to you too !
 
Thanks for your reply.
 
I tested both my standard and mobile broadband connections using the 3MB test URL you provided.
 
The tests confirmed that the 4G connection is much faster than the standard broadband connection - we are in a rural location where the standard broadband links are not good !
 
Time to purchase some pre-loaded SIM cards !!
 
Thanks again for your help with this.
 
 
 
 

From a quick check in TCPView, Google fiber's speed test is multi-threaded.  Based on a test my with my connection (which only peaks about 45Mbps), it made 20 simultaneous connections:
 

Although TestMy has a multi-threaded test option (default test is a single connection), the 200MB maximum block size is not sufficient to properly test Gigabit connections as the test will complete in under 2 seconds (900Mbps = 112.5MB per second).  So for measuring your peak speed, the Google fibre test will likely be more accurate.
 
On the other hand, the normal TestMy linear test will give an idea of what your connection is capable of with a single connection, similar to downloading a very large file with a web browser or FTP transfer.  If you are getting in the 800Mbps range, your connection is fine.  However, if it's much lower, e.g. below 500Mbps, then there is probably something limiting what you can achieve over a single connection, which the multi-threaded speed tests don't show, in which cause you would only be able to achieve the multi-threaded test result with a multi-threaded download manager, e.g. Firefox's DownThemAll plug-in which splits a large download into multiple segments and downloads these segments simultaneously. 

Test run on the Irish Three 4G network in Donegal town, possibly LTE+ (OnePlus 2 phone):
 

 
It's also my fastest TestMy download result to date, certainly did not expect to see my first >100Mbps result on a cellular network, let alone the Three network especially with the past experience of prioritising/throttling ports.  As far as I can tell, they treat port 80 and 8080 equally now and the above test was a normal linear HTTP test with the UK server.

Hey Sean, I didn't see this topic, I got a PM with the same title and ended up responding over there and didn't see this thread.  It was a pretty odd issue that came from an  update of ipb. 
 
Thank you for bringing this to my attention quickly so I could fix it quickly.
 
Happy New Year!!

The spike at the start can sometimes be caused by the Internet Security (virus checker) or the browser itself.
 
For example, many Internet Security products start analysing the data of each connection before passing the data stream to the browser.  In the split second this happens, the data coming in is queued.  Once the Internet security product is satisfied this is not a threat, it passes this chunk along with any queued data to the browser.  To the speed test, this burst of data appears as the spike at the start of the graph.
 
I often see this happen with the Firefox web browser, which also seems to hold up the data stream near the start of the test.  For example, occasionally when I start a speed test, Firefox stutters and then seems to skip ahead 10% where the speed test script sees this chunk as a speed spike.  The following shows an example of the spike where I did a test on Firefox for Android, in this case over the Meteor LTE (4G) network.
 

If this advice was given for a mobile Internet connection, what they likely mean is that running speed tests gobbles up the available data allowance.
 
For example, many of the popular mobile phone packages in Ireland and the UK have a 1GB data allowance, such as the following example I picked from the UK O2 website:
 

Running a speed test on 4G typically uses up to 100MB per direction per test depending on the 4G speed.  For example, if one is getting around 50Mbps, TestMy will usually download about 60MB in total.  This is double for the uplink direction as TestMy first downloads each block size to run the upload test.  So for a typical 20Mbps uplink, it will use around 40MB in total.  For faster 4G areas such as 20MHz areas or LTE Advanced (or 4G+), these figures double or triple.  Speedtest.net uses a similar amount of data, around 100MB total for a 4G connection delivering about 50Mbps down and 20Mbps up and I'm sure it's much the same with other speed test providers. 
 
So assuming a speed test uses about 100MB per test (combined up & down) and the user has a 1GB monthly allowance like the above tariff, that person just needs to run the test 10 times to use up their data allowance without doing anything else online. 
 
Basically, for anyone with a 2GB or lower monthly data allowance on their mobile handset, run the speed tests sparingly on 3G and avoid running speed tests if at all possible on 4G, apart from on the last day of the billing cycle and you have at least 200MB left (500MB for an LTE Advanced / 4G+ area).

As I noticed some ISPs return considerably quicker speed tests with Ookla's speed than what's possible with regular web access including TestMy, I decided to snoop at how Speed test establishes its connection using Sysinternals' TCPView utility.  I sorted the traffic by 'Received Bytes' and then started a speed test.
 
While the multiple connections doesn't surprise me (Ookla's tests are all multi-threaded), what I was surprised with was what port it used - 8080:
 

 
It seemed like no matter what test server I tried, it ran its test over port 8080, which is a seldom used port for web traffic.  For example, HTTP and HTTPS traffic are carried over ports 80 and 443, respectively, while FTP traffic is carried over ports 20 and 21.   Port 8080 is typically used for an internal web proxy within corporate networks and for an ISP cache proxy in the early days of Internet for faster access to popular websites.
 
On the other hand, by running the speed tests over port 8080, this makes it easy for ISPs to prioritise traffic for anyone using Ookla's speed test as all they have to do is give elevated QoS for traffic running over port 8080.
 
I then thought - Is port 8080 necessary for Ookla's Speedtest?  To find out, I blocked port 8080 on my PC.
 
The speed test took a little longer to start, but once it did, it switched over to port 80, in this case with two threads:
 

 
Once I open up port 8080 and click 'Test Again', the next test runs on port 8080 again.
 
So an interesting idea would be if TestMy could add support for port 8080.  I don't think it will require much configuration other than configuring the various test servers to also accept traffic on port 8080.  Then it would just be a matter of typing testmy.net:8080 to perform the test on port 8080 with suspect ISPs, such as those that seem to throttle ports 80 (HTTP) and 443 (HTTPS).

I have the same experience with 4G (cellular LTE) based broadband connections, such as when positioning a directional antenna.  When the network is quiet (e.g. early on a weekend morning), there can be a large variation between what SpeedTest and TestMy reports if the antenna is not aimed correctly.  Once the antenna is carefully aimed, the TestMy results climb up towards what Speedtest reports.  It's similar also if there are swaying branches in line of sight as Speedtest will again ignore the brief dips as if the bandwidth is sustained. 
 
If Speedtest measured road trip speeds, their speed test methodology would eliminate traffic lights, construction zones, slow vehicles, busy junctions and everything else that accounted for the slowest 30% of the journey.
 
If TestMy measured road trips, it would run a stopwatch from the moment of departure to the moment of arrival.
 
Of course like the Speedtest fanatics, there would be those that would argue the same for road trip measurements - "What if that construction zone was not there, those traffic lights were green, no accident on the route, ..." 

Although my LTE connection is limited to about 16Mbps up, it did make a noticeable difference here also:
 
Default (131072) and after (524288):

 
The Android Firefox does not seem to have this setting, however, I have noticed it has been producing faster upload results than Firefox on my PC, so it probably uses a larger send buffer by default.  It consistently produces faster upload results than the Chrome App, which seems to cap out about 12Mbps. 

I noticed that on my computer Firefox by default sets the TCP send buffer equal to 128 KB (about:config -> network.tcp.sendbuffer), which limits the result of a single thread upload test. System default receive buffer is used, so download speed isn't affected. This value is adequate for normal web browsing and uploading to geographically close servers, but cannot be used to measure the best possible performance of bulk file transfers across different applications. Usually software don't set custom buffer sizes, or if they do, they use extreme values (FileZilla uses 4 MB).
I observed the following throughput with FireFox - 128 KB:

384 KB:

512 KB:


 

Getting better over the last month and a half or so. 
 
Right now, with the Gen4 plan, you can still buy the equipment, though I'm not sure how much it is.  $200 maybe?  The Gen4 plans have no free download time.  They have the Anytime Data, which is really the biggest difference between plans, and the Bonus Bytes, which is 50GB with all of the plans.  Anytime Data is 8:00AM to 2:00AM, and Bonus Bytes is 2:00AM to 8:00AM.  If you run out of Bonus Bytes, though, the Anytime Data will be used during Bonus Bytes time, hence the name. 
 
With that said, I prefer to lease the equipment, because if anything goes wrong with it, it's covered.  If you purchase it and later something goes wrong with it, you have to pay to have it fixed, not only for the parts, but the labor, as well.  Sure, in the long leasing costs more, but it's worth the peace of mind. 
 
I have the 15GB/50GB plan.  I don't stream, so it's plenty for me, and for three Windows 10 PCs, too.  I pay about $85 for mine, but I have a 12 month discount.  Normally it would be $79.99 for the plan and $9.99 for the equipment lease, plus tax.  
 
My plan has Smart Browsing, as well.  If I use up all of my data, I can still browse with no noticeable drop in speed.  That's browsing, though.  If you try to download large files while in Smart Browsing, it will throttle you to around 150Kbps.   

At home, my main Internet connection is a DSL connection that gives a fairly consistent 3.9Mbps down and about 400Kbps up.  I tried a fixed wireless service about a year ago that was a complete disaster.  Lately I'm using a makeshift LTE based connection that fluctuates between 4Mbps and 45Mbps down and 10Mbps to 12Mbps up, going by TestMy.  As with phone cellular data connections, the IP address changes quite regularly, likely once or twice a day. 
 
In addition, while out and about, I run tests with my phone's data and similar also in places that offer free Wi-Fi.  I didn't realise just how many different IP addresses I clocked up until I was browsing through the Top 10 list for Ireland. 
 

I'm actually surprised to be in this list also as I certainly don't have the 10,000th fastest connection in Ireland, let alone the 10th.  Just a pity that most people in Ireland don't create an account to log their readings as that #7 rank indeed shows that the majority of tests here are not with a signed in user.