cancel
Showing results for 
Search instead for 
Did you mean: 

Has anybody else encountered corrupted HTTPS streams lately?

Alum

Re: Has anybody else encountered corrupted HTTPS streams lately?

Hi Jackson,

Thanks for the reply. Yes I would recommend calling in instead of chat. You never know if you could be disconnected. I think our system only keeps so many cases up and available for us to see. That may be the reason. Whenever you are able to call, let us know how it goes.

- Chris
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

As for web acceleration, yes, I know it's supposed to be left on, but some testing early on showed me that it generally gets me faster speeds with it off. 

The thing about Web Acceleration is that it can't help with HTTPS traffic, because HTTPS is encrypted between the web browser and the server. (There's no way for the proxy to fetch assets on a page to pipe to the user in one big burst because the page is scrambled from a proxy's point of view.)

I've been wondering what effect things like https://letsencrypt.org and https://www.eff.org/https-everywhere will have on the Web Acceleration system. There's a push for stronger encryption to be deployed on as many websites as possible (in reaction to the NSA programs Snowden revealed) and this is going to reduce the effectiveness of Web Acceleration.

Example: Yahoo used to be unencrypted. When a HughesNet user visited Yahoo, some of the assets (images, etc) from the site would be cached in the Web Acceleration system, and subsequent HughesNet users visiting would be served files from the cache, saving bandwidth between HughesNet's ground stations and the Internet. Now that Yahoo uses HTTPS for everything, those potential bandwidth savings are gone.

Sure, there's popular websites that aren't encrypted, but those numbers may dwindle...

On the flip side, deploying HTTPS on large sites can be really, really annoying. So there's that. Smiley Wink

Anyway, I would test Web Acceleration's effect on unencrypted HTTP, but like I said, I'm running lower on bandwidth than I should be this time of month, so I'll hold off on that. When I do, I need to find a HTTP link that's amiable to repeated disconnections.
Alum

Re: Has anybody else encountered corrupted HTTPS streams lately?

Hi Jackson,

Thanks for the reply. You made some good points. I went ahead and added some token bandwidth to your account. They will take affect as soon as you are out of anytime bandwidth. You should be good to go.

- Chris
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

Thanks, Chris. I'll make a block of free time and call in Monday. I'll let you know how it goes.
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

Hey Jackson

"The thing about Web Acceleration is that it can't help with HTTPS traffic, because HTTPS is encrypted between the web browser and the server"


You may be on to something there it very well could be an encryption problem.  When I tried to access from a XP machine everything downloaded was in encryption code.  So maybe the Hughes network may have a problem reading a certain encryption format.  That would explain why some users could download and some couldn't. It very well could be a browser/OS compatibility problem.  I do not see how an ISP could be the problem but a Satellite encryption software error could. 
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

OH! Sorry, I forgot to warn about that. On IE (and only IE), that .gem file downloads as text. Try right clicking it and "Save Target as..." to force it to download as a file.

It's a problem with that specific file/website, and unrelated to the aborted downloads. Smiley Sad
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

But wouldn't that hint to an encryption problem
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

Nah, it means that the web browser doesn't understand the file-type header the server is sending back (or the server is sending back the incorrect one). 

It's more an "encoding" problem than an "encryption" one. And I bet it's just IE being its usual adorably cross-platform unfriendly self. Smiley Sad
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

Oh that's weird. The server for Nokogiri isn't sending a file type at all.
Resolving rubygems.global.ssl.fastly.net (rubygems.global.ssl.fastly.net)... 23.235.44.249, 23.235.40.249  Connecting to rubygems.global.ssl.fastly.net (rubygems.global.ssl.fastly.net)|23.235.44.249|:443... connected.
HTTP request sent, awaiting response... HTTP/1.1 200 OK x-amz-id-2: ByM8gia0nolX+etXBSv/Tfcbgi3XIBYNsidmfgszUqXUAbUCo5INDm72yqx96MJf x-amz-request-id: 78D1802973F8B4D9 x-amz-version-id: pdgJT1gBUCP97ibZtu77Pn3DMsmT4oH. Last-Modified: Fri, 23 Jan 2015 18:52:50 GMT ETag: "fc9f91534bf93d57b84f625b55732a7c" Content-Type: Server: AmazonS3 Via: 1.1 varnish Content-Length: 9249280 Accept-Ranges: bytes Date: Sat, 25 Jul 2015 00:59:00 GMT Via: 1.1 varnish Age: 3981 Connection: keep-alive X-Served-By: cache-iad2124-IAD, cache-dfw1831-DFW X-Cache: HIT, HIT X-Cache-Hits: 1, 1 X-Log-Message: for=request method=GET path=/production.s3.rubygems.org/gems/nokogiri-1.6.6.2.gem fwd="184.53.49.49" status=200 bytes=9249280 cache=HIT, HIT cache_hits=1, 1 timing="(null)"
IE is probably messing up at the blank "Content-Type". I bet other browsers treat unknown Content-Type as downloads, where IE treats it as text.

Also, that's interesting it's being served through Varnish. Varnish is a reverse proxy, hosted at the website (i.e., it's not a HughesNet thing), that is probably caching and load balancing downloads. I wonder if this relates to the issue in any way...

...Hey, look. Here's the headers the server sends back for the Django download.
Resolving pypi.python.org (pypi.python.org)... 23.235.40.223
Connecting to pypi.python.org (pypi.python.org)|23.235.40.223|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Last-Modified: Wed, 08 Jul 2015 19:43:38 GMT
  ETag: "31760322115c3ae51fbd8ac85c9ac428"
  Content-Type: application/octet-stream
  Server: AmazonS3
  Via: 1.1 varnish
  Cache-Control: max-age=31557600, public
  Content-Length: 7284327
  Accept-Ranges: bytes
  Date: Sat, 25 Jul 2015 01:02:55 GMT
  Via: 1.1 varnish
  Age: 1401528
  Connection: keep-alive
  X-Served-By: cache-sea1922-SEA, cache-ord1725-ORD
  X-Cache: HIT, HIT
  X-Cache-Hits: 2, 1
  X-Timer: S1437786175.691834,VS0,VE24
Interesting. I wonder if Varnish or other reverse proxies are a commonality? Might be very short timeouts or something. I gotta find more problematic downloads to test.

(I got these with wget -S, by the way, if any Linux users want to peek at their own response headers.)
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

Eh, the third file I had trouble with, http://nl.archive.ubuntu.com/ubuntu/dists/vivid/universe/source/Sources.bz2 , is not behind a reverse proxy server. However, it also fails downloading a lot less (I had to try 5-7 times to get an aborted download).

Resolving nl.archive.ubuntu.com (nl.archive.ubuntu.com)... 2001:7b8:3:37::21:3, 213.136.12.213
Connecting to nl.archive.ubuntu.com (nl.archive.ubuntu.com)|2001:7b8:3:37::21:3|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Sat, 25 Jul 2015 01:08:48 GMT
  Server: Apache/2.4.10 (Ubuntu)
  Last-Modified: Fri, 24 Apr 2015 18:45:54 GMT
  ETag: "6b1417-5147cce591c80"
  Accept-Ranges: bytes
  Content-Length: 7017495
  Keep-Alive: timeout=5, max=250
  Connection: Keep-Alive
  Content-Type: application/x-bzip2
Length: 7017495 (6.7M) [application/x-bzip2]
I have a capture for this one, still haven't gotten it cleaned up though.

It might not be Varnish, but the way that Amazon has configured their particular reverse proxies (both Nokogiri and Django are being served from Amazon S3 instances).