Issues with accessing rufus.akeo.ie is or rufus.ie

[pbatard]

2018.10.16 12:15 GMT: Main access to the website should now be restored, including HTTPS. Minor annoyances (check for update, language selection) are still broken, and we are working to fix them, but they are not as high a priority as the rest

Our web site is experiencing a coordinate DDoS attack since earlier today (Can you imagine there's a low life loser out there who thinks that providing a utility for free should be punished? Apparently they weren't smart enough to get back at us through debate, so they had to resort to dumb script kiddie tactics 😄).

We're working on restoring functionality. More information will follow when we have it.

[j0nathontayl0r]

I was about to ask... I can believe it.

Script kiddies, script kiddies every where.

[pbatard]

Or a disgruntled security "researcher"...

The thing is, we have started to accumulate a lot of circumstantial evidence against a specific person, who's definitely not as smart or stealthy as they think they are. So much so that I am wondering how much of it would hold in court, if we were to take legal action against them...

[Ibuprophen]

It's weird that the xda-developers just got done after spending a little over a month with a DDOS attack on the forum server.

Whom ever it is, i hope they get what they deserve!

Your hard work @pbatard is greatly appreciated and I truly wish you nothing but, the best of luck in getting up and running! :-)

~Ibuprophen

[pbatard]

Depending on how fast your DNS servers refresh, you should be able to access the main web page back again at:

• http://rufus.ie

Note that, for now, you will need to use HTTP and NOT HTTPS, as github's automated SSL is currently not playing nice with my website, and anything that revolves around DNS takes hours to sort out due to the extended refresh times...

Unfortunately, due to the modern's browser insistence of using SSL as well as caching, you may get a warning about the site being improperly configured. Also, since I have redirected rufus.akeo.ie to rufus.ie as a CNAME I expect that things are going to be a bit dicey on that front until I invest some more time into it.

Both the main page and the downloads page should be working.

Additional file download (Syslinux, GRUB) has not been restored yet, but then again, as long as we don't have SSL that's kind of moot, since Rufus accesses the download server through SSL.

Quite glad I didn't give in to all these request to "modernise my website" (and increase my "sales", lol) that I have been receiving over the years, and kept the stuff as boring and static as possible, since it makes transitioning to github pages almost a breeze...

The one thing that's going to be a minor issue is going to be automated language selection, but i think there might be some way to sort that out...

Good luck trying to DDoS github pages, sucker!!

[bkkgbkjb]

Hi

sorry for the troubles you're having

Currently I'm able to get all the websites and downloads of rufus .exe work

However, my rufus promts to download Syslinux which as you mentioned, is temporarily down

What should I do to get the files downloaded?
Otherwise my .exe doesn't work...

[pbatard]

@bkkgbkjb, the following:

Additional file download (Syslinux, GRUB) has not been restored yet

is why you are experiencing the download issue. I'm in the process of fixing this, but please be patient, okay.

Also, https://rufus.ie should be working again for the main web page, so no need to use HTTP.

I'll keep you updated here.

[pbatard]

Okay, file downloads for GRUB and Syslinux should work again now.

I also set up a redirect for rufus.akeo.ie & rufus.ie which should help people accessing the older domain, but SSL hasn't kicked in on that, so you're probably going to have issues with that redirection until it does (probably in a few hours, if it's like SSL for rufus.ie).

[bkkgbkjb]

Hi pbatard

Yes, I just tried your awesome rufus and it works perfectly

Sorry for pushing you here on Github

It's just this morning(GMT +8) I decided to reinstall my whole computer

After removing the existing OS, I found your rufus cannot work and had no choice
but to wait for roughly 3 hours

I've tried a lot of similar solutions
none of them works with my Debian netboot mini.iso

Really appreciate your hardwork and contribution on maintaining such a
great utility

[pbatard]

It's just this morning(GMT +8) I decided to reinstall my whole computer

If you really wanna have fun, try reinstalling server content twice, during the same day, whilst being throttled to 80 KB/s by your ISP... 😄

All in all, that's still a lot of fun though, coz I was able to validate that my disaster plan, for just this situation, could indeed work, and right now, the person who attacked me has no more cowardly place to run. They're going to have to do much better than this next time around...

Anyway, glad to hear you sorted out your installation now that the files are back up. And don't worry, people can try to attack us, but, as long as they clearly aren't able to use more than 2 brain cells to do so, there's no much risk that they'll amount to much of anything in terms of preventing you guys from continuing to rely on Rufus!

[pbatard]

• https://rufus.akeo.ie should now be fully available again (if your DNS servers have been refreshed).

[luckman212]

Thanks for everything @pbatard
Can't believe these lowlifes have nothing better to do.

[pbatard]

Since the sites should be accessible again, I'm going to close this issue.

[vntkmr]

While https://rufus.ie is working fine (uses SSL), https://rufus.ie/downloads is redirected to non-SSL http://rufus.ie/downloads. Not sure if it's because of something on my end.

@pbatard thanks for taking care of this whole issue so promptly.

[vntkmr]

Re: the above issue it's working fine now. Thanks!

[pbatard]

Thanks for the report. I can see the same thing too.
However, you have to be mindful not to add a slash after downloads if you want to see it (if using downloads/, which you may get once your browser starts to autocomplete, you will not see it).

The SSL → non-SSL drop seems to be something that github enacts on its own (because I certainly did not add a redirection here):

# curl -v https://rufus.ie/downloads
*   Trying 185.199.111.153...
* TCP_NODELAY set
* Connected to rufus.ie (185.199.111.153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=rufus.ie
*  start date: Oct 16 02:46:21 2018 GMT
*  expire date: Jan 14 02:46:21 2019 GMT
*  subjectAltName: host "rufus.ie" matched cert's "rufus.ie"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0xaaaad8a82ca0)
> GET /downloads HTTP/2
> Host: rufus.ie
> User-Agent: curl/7.61.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 301
< server: GitHub.com
< content-type: text/html
< location: http://rufus.ie/downloads/
< access-control-allow-origin: *
< expires: Wed, 17 Oct 2018 16:15:37 GMT
< cache-control: max-age=600
< x-github-request-id: 7C5A:4AC9:A2662B:DEBFE0:5BC75DD1
< accept-ranges: bytes
< date: Wed, 17 Oct 2018 16:12:58 GMT
< via: 1.1 varnish
< age: 441
< x-served-by: cache-lcy19224-LCY
< x-cache: HIT
< x-cache-hits: 1
< x-timer: S1539792779.834767,VS0,VE0
< vary: Accept-Encoding
< x-fastly-request-id: f5ee22f68964756a82c82ae6e517bf515f694373
< content-length: 178
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host rufus.ie left intact

In the above, the important part is the location: http://rufus.ie/downloads/ which tells the browser where the 301 redirection should point to. And as we can see, even as the request was for https, the redirection goes to http. Not sure what the rationale is for github not to remain with SSL, so I'll see what I can dig.

Now of course, one thing I can probably do is force SSL always, which is an option github provides, and which should solve the matter. However, I am a bit reluctant to do that as there are still some people running older versions of Windows (namely XP) who then are unlikely to be able to access the website. At least, I found that was an issue on the dedicated server I was using, which is why I made sure that SSL was not set to mandatory. And before people say "Who still cares about XP" (which, otherwise, I'd be the first to utter), the thing that makes Rufus special in that respect is that it is a tool that is meant to help people move away from XP, once they agree (at long last!) that XP has overstayed its welcome. Therefore, as much as I don't want to care about XP, preventing people who want to ditch XP, from accessing one of the utilities that can help them do so, is something I would like to avoid...

Anyway, I need to look into it some more, and I will post an update when I have more data on what to do.

[vntkmr]

@pbatard thanks for looking into the issue and the explanation. It's weird that GitHub does the https to http redirect for a sub-URL.

[pbatard]

Hmmm, I have now enforced both rufus.ie and rufus.akeo.ie to use SSL always from the github interface (which means that any request to http://... should be converted to https://...) but that doesn't seem to change anything for https://rufus.ie/downloads.

This is definitely a github issue, as reported in isaacs/github#289. According to the last entry there (from 2 days go), GitHub support reported:

This redirection quirk that you've discovered is a known issue, and relates to trailing slashes and how our redirects work at the moment. Making a request to a URL without a trailing slash will cause redirections to run in this order:

• request to original URL
• 301 to HTTPS version of original URL
• 301 to HTTP version with added trailing slash
• 301 to HTTPS version with added trailing slash

Always including the trailing slash will allow you to skip the extra redirects:

• request to URL with trailing slash
• 301 to HTTPS version of original URL

We have an issue open internally to hopefully improve this situation, but investigations have demonstrates that it is a non-trivial issue to resolve.

[Ibuprophen]

It's a weird thing...

URL:
https://rufus.ie/downloads

Results:
https://rufus.ie/downloads
301 Moved Permanently
http://rufus.ie/downloads/
301 Moved Permanently
https://rufus.ie/downloads/
200 OK

ToolBot Headers Log.txt

~Ibuprophen

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.