Marble Blast Platinum Support

We encourage you first of all to find solutions to your problem in this section's threads. If you do not thus find any solution, please take account of the following:

If you have a problem which prevents you from playing Marble Blast Platinum, please create a new thread on this board with a description of your problem as title. In your post please indicate the computer involved (Mac/PC, operating system).

If in playing Marble Blast Platinum you discover a bug, please post in the Community found Bugs/Mistakes sub-board.

If you need hints for the Marble Blast Platinum game, please post in the Hints, Videos and other Tips sub-board.

file For players on a very old macOS (like 10.9 old): Accessing Online

  • HiGuy
  • HiGuy's Avatar Topic Author
  • Offline
  • Lead Developer
  • Lead Developer
  • PQ Developer Emeritus
09 Apr 2020 04:47 #1 by HiGuy
On old versions of macOS, PQ cannot verify the HTTPS/TLS for marbleblast.com because the system's root cert for Cloudflare (who do our TLS) is expired. Basically this means that you cannot play online because the game cannot verify that our server is legit.

If you experience this, you can add the following to the end of platinum/client/mbpPrefs.cs:
$pref::SSL::VerifyPeer = 0;

This will make your game stop trying to check that marbleblast.com is verified and connect anyway. Note this opens you to man-in-the-middle attacks on your network, but if you're still running macOS 10.9 you've got bigger security problems...

Ask RandomityGuy about RLib.dll`10001c60
function clientcmd12dothepq() {
    commandToClient(LocalClientConnection, '34onthedancefloor');
The following user(s) said Thank You: Myrus

Please Log in or Create an account to join the conversation.

23 May 2020 07:16 - 31 May 2020 04:44 #2 by krackers
I don't think it's a root cert issue per se since Baltimore CyberTrust is indeed present in keychain and works fine in Chrome (which uses the native certs, unlike Firefox which bundles its own). Interestingly though Safari doesn't validate the chain despite the cert appearing to validate fine in the info pane as mentioned in [1]. Native curl doesn't like the chain either.

Aside from your mentioned workaround, you might consider shipping openssl with its own cert bundle and a libcurl built against that.

[1] community.cloudflare.com/t/safari-6-0-3-cant-verify-the-identity-of-the-website-on-https-site-version-but-other-browsers-works-fine/48534

Edit: Chrome seems to have a more robust implementation of certificate verification [2] that also accounts for some flaws in OS X/Security.framework. The only special case for Baltimore certs is about one cross-signed by GTE CyberTrust (which did expire in 2018). Cloudflare only sends up to the ECC CA-3 intermediate though so that issue shouldn't apply (and validation still fails even with GTE deleted), so I'm still not quite sure why curl (and safari) don't validate. Curl & Safari seem to use apple's native secure transport implementation over openssl, so I'm guessing the issue lies somewhere there – looking at curl source as an example, it directly calls into secure transport's SSLHandshake() and relies on the system's cert verification rather than manually verifying the cert chain via the SecTrust* apis as Chrome does.

[2] chromium.googlesource.com/chromium/chromium/+/trunk/net/cert/cert_verify_proc_mac.cc#442

Edit: Oh that chromium source code is long out of date. The newer version of cert verification [3] has a much better comment
OS X lacks proper path discovery; it will take the input certs and never
  // backtrack the graph attempting to discover valid paths.
  // This can create issues in some situations:
  // - When OS X changes the trust store, there may be a chain
  //     A -> B -> C -> D
  //   where OS X trusts D (on some versions) and trusts C (on some versions).
  //   If a server supplies a chain A, B, C (cross-signed by D), then this chain
  //   will successfully validate on systems that trust D, but fail for systems
  //   that trust C. If the server supplies a chain of A -> B, then it forces
  //   all clients to fetch C (via AIA) if they trust D, and not all clients
  //   (notably, Firefox and Android) will do this, thus breaking them.
  //   An example of this is the Verizon Business Services root - GTE CyberTrust
  //   and Baltimore CyberTrust roots represent old and new roots that cause
  //   issues depending on which version of OS X being used.
  // - A server may be (misconfigured) to send an expired intermediate
  //   certificate. On platforms with path discovery, the graph traversal
  //   will back up to immediately before this intermediate, and then
  //   attempt an AIA fetch or retrieval from local store. However, OS X
  //   does not do this, and thus prevents access. While this is ostensibly
  //   a server misconfiguration issue, the fact that it works on other
  //   platforms is a jarring inconsistency for users.
  // - When OS X trusts both C and D (simultaneously), it's possible that the
  //   version of C signed by D is signed using a weak algorithm (e.g. SHA-1),
  //   while the version of C in the trust store's signature doesn't matter.
  //   Since a 'strong' chain exists, it would be desirable to prefer this
  //   chain.
  // - A variant of the above example, it may be that the version of B sent by
  //   the server is signed using a weak algorithm, but the version of B
  //   present in the AIA of A is signed using a strong algorithm. Since a
  //   'strong' chain exists, it would be desirable to prefer this chain.
  // - A user keychain may contain a less desirable intermediate or root.
  //   OS X gives the user keychains higher priority than the system keychain,
  //   so it may build a weak chain.
  // Because of this, the code below first attempts to validate the peer's
  // identity using the supplied chain. If it is not trusted (e.g. the OS only
  // trusts C, but the version of C signed by D was sent, and D is not trusted),
  // or if it contains a weak chain, it will begin lopping off certificates
  // from the end of the chain and attempting to verify. If a stronger, trusted
  // chain is found, it is used, otherwise, the algorithm continues until only
  // the peer's certificate remains.
  // If the loop does not find a trusted chain, the loop will be repeated with
  // the keychain search order altered to give priority to the System Roots
  // keychain.
  // This does cause a performance hit for these users, but only in cases where
  // OS X is building weaker chains than desired, or when it would otherwise
  // fail the connection.

Again, none of those conditions seem to apply directly; it'd still be quite interesting to find out why these chains in particular fail.

[3] chromium.googlesource.com/chromium/src/+/master/net/cert/cert_verify_proc_mac.cc
Last edit: 31 May 2020 04:44 by krackers.

Please Log in or Create an account to join the conversation.

Moderators: DoomblahGo'way