1133496 - *.userstorage.mega.co.nz - file upload does not work for some users

Status: VERIFIED FIXED

(Web Compatibility :: Desktop, defect)

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Guys do you have an idea what can be the culprit and which bug block here?

Some more info:
https://www.ssllabs.com/ssltest/analyze.html?d=mega.co.nz
https://sslcheck.globalsign.com/en_US/sslcheck/?host=mega.co.nz#154.53.224.146

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

In Error Console I'm seeing 2 warnings :


Timestamp: 2015-02-16 14:01:52
Warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://eu.static.mega.co.nz/lang/en_27.json. (Reason: CORS request failed).

Timestamp: 2015-02-16 14:01:52
Warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://eu.static.mega.co.nz/sjcl_1.js. (Reason: CORS request failed).


and 1 error:


Timestamp: 2015-02-16 14:01:52
Error: An error occurred during a connection to eu.static.mega.co.nz:443.

Cannot communicate securely with peer: no common encryption algorithm(s).

(Error code: ssl_error_no_cypher_overlap)

Comment 2

[Matthias Versen [:Matti]]

You have tested the wrong server. You can see the right one in the Error message that you have posted.

https://eu.static.mega.co.nz/ -> https://www.ssllabs.com/ssltest/analyze.html?d=eu.static.mega.co.nz&s=154.53.224.134&latest

Supported are TLS1.0 and SSL3 and as supported Ciphers only TLS_RSA_WITH_RC4_128_MD5 and bug 1124039 caused the "no_cypher_overlap" error

Comment 3

[Alyssa Rowan]

Thanks: I've spoken with them before a couple of years ago in fact, so I've just raised that with MEGA's team to sort out.

It's more of a compatibility issue for them than security, as the static files are SHA-256 hash-pinned by the root JS.

I'll let you know when I hear back.

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I get reply from MEGA, as I also reported it on their support email like Alyssa Rowan.
I think it's worth to share, so:





"Thank you for your support and thank you for using MEGA!

Our developers advised: "We are only serving public static content from mega.co.nz. We do NOT use PFS on static servers (as a honeypot to security researchers) - only where it makes a difference."

MEGA's users get to enjoy the privacy of their data with our User Controlled Encryption (UCE) mechanism - the only storage provider on the market offering this level of security and privacy.

The nominated and confirmed password for your MEGA account is also your unique master encryption key to your files. You could have noticed this being created upon your 'confirmation email' validation. The encryption key gets created from your password and to strengthen the key we have collected the entropy from your mouse movements and key stroke timings. Remember to keep your MEGA password secure and confidential at all times and generate your MASTER CRYPTO KEY for the event of misplacing your password in the future - https://mega.co.nz/#backup.

All files stored on MEGA are encrypted. All data transfers from and to MEGA are encrypted. And while most cloud storage providers can and do claim the same, MEGA is different – unlike the industry norm where the cloud storage provider holds the decryption key, with MEGA, you control the encryption, you hold the keys, and you decide who you grant or deny access to your files, without requiring any risky software installs. It’s all happening in your web browser!

All our encryption is end-to-end. Data uploaded is encrypted on the uploading device before it is sent out to the Internet, and data downloaded is decrypted only after it has arrived on the downloading device. The client machines are responsible for generating, exchanging and managing the encryption keys. No usable encryption keys ever leave the client computers (with the exception of RSA public keys).

We are not sending the password across the net. The server sends an encrypted RSA private key that gets decrypted by the password. Then, the server sends a random number encrypted to the user's public key.
If the user can correctly decrypt it, the server allows the login. We have replaced the Stanford crypto library with our own implementation based on asm.js recently.
Is there any risk if I use RC4?

There is no need to worry. Anything we do send through RC4 is already encrypted from the point it leaves your browser so there is no security risk. For increased security make sure you have our browser extensions installed. MEGA's users get to enjoy the privacy of their data with our User Controlled Encryption (UCE) mechanism - the only storage provider on the market offering this level of security and privacy.

We are now conducting a single node tests to see in how much the server load will increase when using AES instead of RC4 so we can provide an alternative to those who have turned off RC4.

For our customer's sake, some things are really important to us. One of these things is obviously security, whereas another one is performance. However, the former cannot be trumped by the latter!!!

When you log in, receive the `secureboot.js` file, or when you're connecting to our API, you will *always* be running through a properly configured web server, which will give you strong authentication, strong encryption, as well as forward secrecy (PFS). These are the places where it matters that information is transferred in a secure fashion when using SSL/TLS!

Afterwards, when you're accessing further static content, or when you're accessing your file storage, the client side (that is for example the JavaScript code in your browser, a browser extension, a
sync client or a mobile app) will take care of ensuring security. Every content further loaded off of servers (e. g. the *.static.mega.co.nz servers) will be verified cryptographically by the client, and the content that could be seen on the wire is harmless. Every time data is transferred to or from our storage servers, the client side code will take care of proper, strong encryption, so that only ever the client alone is able to get access to the actual plain data.

Given these circumstances, we could actually serve all static content and/or data transfers with our storage servers over a completely unencrypted connection. There would be *no* lack in security!

However, browsers will refuse to allow for unencrypted HTTP connections (for good reasons) when originating from an HTTPS encrypted site, or they will at least display a degradation in security in the browser bar. This is all very good and common practice, especially if SSL/TLS is your line of defence when transmitting plain text data. For those reasons also, all subsequent connections generally should be of similar good strength in protection. However, as stated above, we don't actually need an encrypted HTTPS connection to uphold our protection (as we've taken care to completely encrypt the actual content already). But, we can't remove SSL/TLS (HTTPS) completely, as that would make the look in the browser "unhappy". Therefore, we have opted to use the weakest
possible protection (RC4 with MD5) as a "NULL cipher" to prevent the browser from alarming people, whereas we would even be happy with an unencrypted connection altogether. This will give the end user an enhanced performance, *without* decreasing any security. And this is actually what our other clients are doing, they're getting rid of even RC4/MD5, but use strong SSL/TLS where needed.

I hope this rather lengthy description has cleared up the situation, and lets you enjoy MEGA without a stale feeling of insecurity or security by hand waving. We really do take it seriously, and have put
*lots* of thoughts into it.

For more information please read: https://mega.co.nz/#blog_32





Kind Regards,
Mega Support

Follow us on https://www.facebook.com/MEGAprivacy https://twitter.com/MEGAprivacy & https://mega.co.nz/#blog

Ticket Details
Ticket ID: URE-258-51769
Department: Support
Type: Issue
Status: Pending
Priority: Normal

Helpdesk: https://support.developers.mega.co.nz/index.php?"

Comment 5

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: MEGA.png

Using latest Nightly form the inbound with backed out bug #1124039,
MEGA is still behaving odd in Nightly as I see exclamation mark in triangle and "Broken Encryption" in security, instead of a green or even gray padlock.

Comment 6

[Masatoshi Kimura [:emk]]

The exclamation mark in triangle is expected. We will show the warn icon if any subresources use a weak enxryption.
But "Broken Encryption" message is a regression from bug 1126413. Filed bug 1134086.

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

It looks like the main problem for MEGA site that's not displaying and it's all white without any content in latest Nightly is gone now due to relanding bug #1124039 with whitelist update bug #1133187.



Unfortunately, I'm still unable to use MAGE site for upload as "Update failed" is showing in the latest Nightly.



In Error Console I'm seeing:


some errors:
Timestamp: 2015-02-23 13:55:28
Error: eu.api.mega.co.nz : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 2015-02-23 13:55:28
Error: w.api.mega.co.nz : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 2015-02-23 13:55:28
Error: mega.co.nz : server does not support RFC 5746, see CVE-2009-3555


many warnings for images:
Timestamp: 2015-02-23 13:55:28
Warning: This site uses the cipher RC4 for encryption, which is deprecated and insecure.
Source File: https://eu.static.mega.co.nz/images/mega/*
Line: 0

many warnings when trying to upload file:
Timestamp: 2015-02-23 13:57:58
Warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://*.userstorage.mega.co.nz/*/*. (Reason: CORS request failed).

and other warnings like this
Timestamp: 2015-02-23 13:55:28
Warning: Use of getPreventDefault() is deprecated.  Use defaultPrevented instead.
Source File: blob:https://mega.co.nz/*
Line: 8787



Should we close this bug as fixed or worksforme per update in bug #1124039 and bug #1133187,
and let start the next issue be tracked in a new bug or we can leave it as open and monitor it also here?

Comment 8

[Masatoshi Kimura [:emk]]

We'll remove the site from the whitelist once the site is fixed. Please do not close the bug until the site fix the issue.

Comment 9

[Masatoshi Kimura [:emk]]

> https://*.userstorage.mega.co.nz/*/*. (Reason: CORS request failed).

And the current whitelist infrastructure does not support such wildcard domains...

Comment 10

[Gabriela [:gaby2300]]

Looks fine to me using Windows 7 and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0

Comment 11

[Masatoshi Kimura [:emk]]

Does the file upload work? Looks like *.userstorage.mega.co.nz still depends on RC4.

Comment 12

[Gabriela [:gaby2300]]

Yes, file upload works fine.

Comment 13

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Masatoshi Kimura [:emk] from comment #11)
> Does the file upload work? Looks like *.userstorage.mega.co.nz still depends
> on RC4.

No, it still not works.
I'm still seeing these Errors in Error Console

Timestamp: 2015-03-02 17:17:26
Error: eu.api.mega.co.nz : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 2015-03-02 17:17:26
Error: w.api.mega.co.nz : server does not support RFC 5746, see CVE-2009-3555

and many Warnings like these:
Timestamp: 2015-03-02 17:17:34
Warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://*.userstorage.mega.co.nz/ul/*/* (Reason: CORS request failed).



(In reply to Gabriela [:gaby2300] from comment #12)
> Yes, file upload works fine.

No, it not works fine in latest Nightly.

Comment 14

[Masatoshi Kimura [:emk]]

Example URL: https://gfs204n006.userstorage.mega.co.nz

Comment 15

[Gabriela [:gaby2300]]

(In reply to Masatoshi Kimura [:emk] from comment #14)
> Example URL: https://gfs204n006.userstorage.mega.co.nz

In Windows 7 32bit and 64bit using:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150302030204
Version: 39.0a1

I don't get any warnings and the site looks fine. 
Your site shows the following though: Secure Connection Failed, The connection to gfs204n006.userstorage.mega.co.nz was interrupted while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

Comment 16

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Masatoshi Kimura [:emk] from comment #14)
> Example URL: https://gfs204n006.userstorage.mega.co.nz
Secure Connection Failed
The connection to gfs204n006.userstorage.mega.co.nz was interrupted while the page was loading.

So I'm having the same error like Gabriela [:gaby2300]



(In reply to Gabriela [:gaby2300] from comment #15)
The errors and warnings are in Error Console.
You're probably using MEGA addon, so maybe that's why you're not seeing any issues with uploading files. I'm having problems even with Nightly Portable with clean new fresh profile without any addons and plugins.

Comment 17

[Gabriela [:gaby2300]]

> (In reply to Gabriela [:gaby2300] from comment #15)
> The errors and warnings are in Error Console.
> You're probably using MEGA addon, so maybe that's why you're not seeing any
> issues with uploading files. I'm having problems even with Nightly Portable
> with clean new fresh profile without any addons and plugins.

I don't have issues uploading but not due to the MEGA addon because I don't have it installed.

Comment 18

[Masatoshi Kimura [:emk]]

The latest Nightly (20150303030230) should have the bug 1137179 fix. Do you still see the error? If so, it is a different problem from this bug.
Note that messages about RFC 5746 are just warnings and should have no functional issue.

Comment 19

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Yes, with latest Nightly (ID:20150303030230) [rev:0b3c520002ad] I'm finally able to upload files to MEGA.



No more Warnings like these in Error Console:
Timestamp: 2015-03-02 17:17:34
Warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://*.userstorage.mega.co.nz/ul/*/* (Reason: CORS request failed).



Only a few Warnings in Error Console like this:
Timestamp: 2015-03-04 12:32:51
Warning: This site uses the cipher RC4 for encryption, which is deprecated and insecure.
Source File: https://*.userstorage.mega.co.nz/*/*
Line: 0

and 

only a few Errors in Error Console like these:
Timestamp: 2015-03-04 12:32:51
Error: *.userstorage.mega.co.nz : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 2015-03-04 12:32:51
Error: eu.api.mega.co.nz : server does not support RFC 5746, see CVE-2009-3555

Timestamp: 2015-03-04 12:32:51
Error: w.api.mega.co.nz : server does not support RFC 5746, see CVE-2009-3555


so everything is working now correctly.

Thank you very much! :)

Comment 20

[Masatoshi Kimura [:emk]]

Changing summary to clarify the current issue.

Comment 21

[Masatoshi Kimura [:emk]]

Fixed.

Comment 22

[Masatoshi Kimura [:emk]]

> Whiteboard: [fixed by patch from bug #1137179]

No, *.userstorage.mega.co.nz now supports AES128-CBC.