[HN Gopher] Gfycat has been down for two days due to an expired ...
___________________________________________________________________
Gfycat has been down for two days due to an expired SSL certificate
Author : thorum
Score : 79 points
Date : 2023-05-20 19:23 UTC (3 hours ago)
(HTM) web link (old.reddit.com)
(TXT) w3m dump (old.reddit.com)
| tpmx wrote:
| "Gfycat is currently owned by Snapchat." (Wikipedia.)
|
| Edit: That appears to have been incorrectly removed by someone
| who was probably reading my comment.
|
| News of Snap Inc acquiring Gfycat can be seen here:
|
| https://www.linkedin.com/company/gfycat/about/
|
| > Gfycat (acquired by Snap Inc)
|
| https://finance.yahoo.com/news/meta-fights-overturn-uk-order...
| (Reuters, april 2022)
|
| > Snap later acquired Gfycat, a competitor to Giphy.
|
| https://www.adweek.com/social-marketing/meta-loses-tribunal-...
| (oct 2022)
|
| > and Snap, which owns Gfycat.
| Aachen wrote:
| Huh, I thought it was Facebook's. The source on Wikipedia has a
| surprisingly helpful title:
|
| > Meta fights to overturn UK order to sell Giphy
| paulgb wrote:
| This has been removed. It seems that whoever added it confused
| Gfycat with Giphy (afaik they have no relation)
|
| https://en.m.wikipedia.org/wiki/Special:MobileDiff/115601663...
| tpmx wrote:
| Incorrectly removed.
| ihuman wrote:
| It was restored
| paulgb wrote:
| Oh you're right, I missed this line in the cited article:
|
| > Snap later acquired Gfycat, a competitor to Giphy.
| jeroenhd wrote:
| If you're looking to archive/download/whatever the images on
| gfycat.com, you can do the following:
|
| 0. This process only works in Chrome(-based) browsers
|
| 1. Open each of the following domains:
|
| - gfycat.com
|
| - api.gfycat.com
|
| - weblogin.gfycat.com
|
| - thumbs.gfycat.com
|
| 2. You will see a scary HTTPS warning. This is fine.
|
| 3. Type "thisisunsafe" into the page (no need to select anything
| or click and input field). This overrides any and all HTTPS
| errors that aren't technical issues.
|
| 4. After doing this for every domain, the HTTPS errors will be
| ignored for the rest of the session and the site will work again.
| If anything is still broken, hit F12 for the dev tools and check
| the network tab to see what domains failed and maybe try the
| above again.
|
| Two days of downtime starting on a week day is not a good sign.
| Back up any images you want to keep!
| yegle wrote:
| https://chromium.googlesource.com/chromium/src/+log/refs/hea...
| and here's where this is defined in the source code. It's a way
| to bypass the SSL errors due to the HSTS headers.
| tommoor wrote:
| > Type "thisisunsafe" into the page
|
| great tip
| explaininjs wrote:
| Is there any actual benefit to auto-expiring SSL certs?
| Presumably if your SSL cert is leaked, you would like to have the
| ability to revoke it without waiting a full year or whatever. On
| the flip side, if your SSL cert isn't leaked it benefits quite
| precisely nobody to have it become invalid just because a
| caesium-133 atom has gone through however many transitions.
|
| The only benefit I've heard voiced is that it forces
| organizations to develop processes for cycling said certs - but
| that's absolutely bogus. Imagine if S3 auto-deleted all buckets
| after a number of days and said "This is a good thing! Us auto-
| deleting these buckets forces you to set up processes to deal
| with us auto-deleting these buckets! You're welcome."
| philipkglass wrote:
| I tried disabling certificate validation so I could browse the
| site again. It looks like there's still text and some generic
| images there, but I wasn't able to load a couple of user-uploaded
| content images that I already had the URLs for. The site appears
| to be hollowed out from the inside, regardless of the cert
| problems.
| thorum wrote:
| From other discussions on Reddit, it seems that the upload
| function has been broken since March.
| Aachen wrote:
| Upload worked for me, I think in April some time, but my gif
| never made it into the search, I can only direct link its
| page. Thought it was some untrusted new account issue
| RulerOf wrote:
| I'm a little surprised by this. They're using an AWS Certificate
| which means the entire certificate lifecycle should be fully
| automated[1]. Assuming they use DNS validation, I speculate that
| somebody deleted the validation CNAME record and then the doom-
| and-gloom renewal emails went to an unmonitored mailbox. Then
| they ignored it so long it ended up on HN.
|
| Gfycat publishes an HSTS header, so they're under _hard_ downtime
| too.
|
| 1: https://docs.aws.amazon.com/acm/latest/userguide/managed-
| ren...
| web007 wrote:
| Most likely someone stopped paying the AWS bill. If you `curl
| -k` to avoid the HSTS problem you see that CloudFront and/or
| lambda aren't working either.
| aaomidi wrote:
| An RFC draft I've been working on tries to address this
| somewhat:
|
| https://datatracker.ietf.org/doc/draft-todo-chariton-dns-acc...
| Animats wrote:
| Do we really need full encryption and signing for cat videos?
| aaomidi wrote:
| Yes.
|
| https://doesmysiteneedhttps.com/
| pxmpxm wrote:
| Yeah, no. Not all traffic matters.
| Lammy wrote:
| Strong disagree. Requiring TLS has made the web less private,
| not more, because now every request has to hit origin servers
| and can't be proxied at network edges like I used to do with
| Squid. Every single connection now gives away metadata about
| my browsing habits. It doesn't matter that the contents of
| those connections are encrypted:
| https://kieranhealy.org/blog/archives/2013/06/09/using-
| metad...
|
| I run TLS on all of my sites, but it's one more thing making
| hosting harder for an average person and one more thing
| driving people into walled gardens. Even "professional" sites
| now fall apart if not maintained as evidenced by the
| submission we're commenting on. Even automatic LetsEncrypt is
| still a moving part that has the possibility to fail in <x>
| number of ways that plain-files-in-a-directory-behind-httpd
| never could. Snowden showed us that the Internet is a giant
| spy machine, and our response was to get Google Analytics
| running over TLS and to make sure every independent site now
| comes with a built-in expiration date. Cosmic irony.
| bastawhiz wrote:
| > now every request has to hit origin servers and can't be
| proxied at network edges like I used to do with Squid
|
| And presumably you ran your own DNS servers as well? And
| ensured your proxy wasn't in turn being monitored?
|
| And what's stopping you from middleboxing your own traffic
| and re-encrypting it with a root certificate? Your
| technically complex privacy solution is still technically
| possible.
|
| > making hosting harder for an average person
|
| The average person isn't running squid. And the average
| person uses a service to host their website which will take
| care of the certificate for them.
|
| > Even automatic LetsEncrypt is still a moving part that
| has the possibility to fail in <x> number of ways that
| plain-files-in-a-directory-behind-httpd never could.
|
| In all my life, I've never had downtime due to an automatic
| certificate renewal failing. And I get an email when my
| certificates are almost ready for renewal. But I have had
| downtime because the httpd logs filled up the disk. And
| because my box had gotten popped because I was on an
| insecure, outdated kernel. And once because I was FTPing
| plain-files-in-a-directory at the same time as someone else
| was FTPing those same plain-files-in-a-directory.
|
| The web never has been some impervious concrete thing that
| has been made complicated and brittle with HTTPS. We live
| in an era where HTTPS is fewer than five commands that you
| run a single time. And if you truly need anonymity to the
| point where you don't want to reveal the origins you're
| connecting to, use Tor.
| giantrobot wrote:
| > And presumably you ran your own DNS servers as well?
| And ensured your proxy wasn't in turn being monitored?
|
| I'm not defending anything else in the GP's comment (I
| think they're 100% wrong) but they meant running Squid as
| a transparent caching proxy. In the dial-up days I ran
| Squid as a transparent proxy on a Linux box that shared
| the dial-up connection for the network. You'd set Squid
| to have a large cache with a long expiry. That way all
| the styles, scripts, and images for pages would get
| cached on the proxy. Subsequent page loads, even days
| later, would be super fast since many of the resources
| would be loading from Squid's cache.
|
| I even had some scripts that I'd run every week in the
| middle of the night (modem speaker disabled obviously) to
| load the homepage to a bunch of sites I visited regularly
| to freshen the cache. Unlike a browser cache the Squid
| cache worked across machines and was much easier to set
| long expiries and just cache way more content.
|
| It improved browsing significantly especially since even
| with a 56k modem I rarely got better than a 28.8k
| connection. While for me personally this kind of thing is
| no longer necessary it's not the worst thing if you've
| got a slow or unreliable connection. With TLS everywhere
| setting up such a transparent caching proxy is much more
| difficult since you need a literal MITM proxy to make it
| work right.
| aaomidi wrote:
| It's easier for random individuals to do https due to
| software like caddy than companies that have to worry about
| the entire certificate lifetime.
|
| You can still MITM yourself and cache data. Literally
| nothing is stopping you from resigning your own traffic.
| Companies do this all the time within their own network.
| giantrobot wrote:
| >because now every request has to hit origin servers
|
| That's not even close to true.
___________________________________________________________________
(page generated 2023-05-20 23:01 UTC)