]> Posts for September 2019 🌐:aligrant.com

Ghost Recon Breakpoint review - more The Division Breakpoint

Alastair Grant | Sunday 29 September 2019

UBISoft have had a couple of betas for the upcoming Ghost Recon: Breakpoint game, being a fan of Tom Clancy shooters, and recently completing Ghost Recon: Wildlands, I thought I'd take a look at the successor.

Rainbow Six has always dealt with close-quarters, indoor operations (e.g. extract the hostage), where Ghost Recon has focused on the outside world, open terrain taking out enemy installations.  Breakpoint continues this theme, with a large open-world environment scattered with various checkpoints and installations that need clearing out (albeit it temporarily).

This is not Wildlands

Breakpoint pushes the emphasis on Stealth a bit more than Wildlands, no longer having an AI squad to cover your back and revive you when things go south, this is much more a lone-wolf style game, which whilst not true to Ghost Recon games does provide you with a drone that can be used to keep tactics involved.

Just like Wildlands, there are hot spots for enemy NPCs who can spot you from a long way off and instantly know that you're a hostile and not one of their own - a continual grievance of mine in open world games.  You have a mini-map that has a heat map of enemy locations and markers for detected hostiles (which is disabled on higher difficulty levels).  You have the option of "going loud" but that elicits a response from the AI which includes hunting you down.  Once your position has been given away that information is instantly available to other AI, although you still have that window from disturbing AI whilst undetected before the rest of the enemies becoming aware.

There is a liberal scattering of vehicles meaning you shouldn't ever be too far away from transport.  For an enemy with access to cutting edge technology there is an alarming number of broken down vehicles being worked on by soldiers that you can commandeer and drive away in (guess they didn't try turning the key?).  The vehicles don't feel as fun or as quick as in Wildlands, there seems to be a slight disconnect between the noise they make and the apparent lack of rotational speed of the wheels.

This is probably the end of the similarities to Wildlands.

This is The Division

The similarities to The Division on the other hand come in thick and fast.  The loot system of Wildlands, where you can unlock weapons or attachments for weapon classes, has been changed to a system similar to The Divison.  Weapons aren't a one off unlock now, you can find better versions of the weapon you already have with more magical bonuses assigned to them and you rapidly build up an inventory of duplicates with differing stats that you then have to deconstruct into parts to use for mods to invest in upgrading your weapon.  These mods do stick so when you find a better version of the same gun, your upgrades are instantly provided - somehow.

A seemingly arbitrary number is assigned to each lootable object, which gives your character a gear-level, which doesn't seem to mean anything apart from if you're not at a certain gear-level then you don't get good drops, meaning you can't upgrade your weapons.  Oh, and of course, the AI damage will scale magically with your gear-level.  I found much of the beta I was spending time trying to manage my inventory and weapons and not shooting things.  This is a bad thing.

You will also find a central hub/lobby where you can find stations and watch through lengthy and largely pointless scripted cut-scenes before going through the treacle run as you half-jog for 45 seconds to get to the exit where you can play the game.  Outside in the game you're a lone-wolf, surviving on your wits as the only man standing against the evil rulers of the island; inside there is a hustle and bustle of human players in a lobby environment, armed to the teeth in all sorts of fancy outfits.

There is a shop with a random number generator assigned to it so you can get some good stuff if you're lucky.  All of which you have to pay for, because their rebellion is not prepared to let you help without some remuneration.

The skill tree leans heavily towards The Division over Wildlands.  Where the latter was a simple case of unlocking upgrades, we're now faced with a more complex tree of perks, which once you've unlocked you have to assign into a limited number of slots.  I found it frustrating in Wildlands having to dig around my inventory for my preferred weapon for the type of situation I was in, this has been made far worse, with frequent trips into the highly complex menu system to switch your perks and load out for varying needs.

In Conclusion

Ghost Recon: Breakpoint is not a stealth shooter, it's now a looter shooter and primary focus is around gear management.  The story seems to be simple, but hidden behind long conversations and cut-scenes that add little value to the game.  There must be many hours of voice acting recorded for the game.  Where Wildlands was a pick up and play, Breakpoint feels like a challenge to find the play.

It seems to be following a common theme with games at the moment, which is about loot and inevitably premium stuff that can be bought with cash or gambling.  Whilst paid-items are unlikely to be game impacting, they're now the focus of the game instead of the shooty shooty bit.

It feels like ultimately what UBISoft have done is taken the bad bits from Wildlands and merged it with the bad bits from The Division and produced a product that you're fighting against, instead of an enemy to fight.  I won't be picking up the full priced game when released (an eye-watering £50 for the basic PC edition, going up to £92 for some of that premium content).  I might have a crack at it when it inevitably drops down to a more palatable £15 in a sale, but even then, I have a long list of games that look far more enjoyable and exciting to play first.

As always, games are subjective and your mileage may vary.  I assume that the younger generation of gamers like the looting system that is so popular at the moment, which is why they keep making games like this.  For the older generation that prefer gameplay, this might be one to avoid.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

MSMQ: The signature is invalid.

Alastair Grant | Friday 27 September 2019

I have recently deployed an application to a new server which is failing to send authenticated MSMQ messages locally.

The Windows Application log was recording Event ID 2196:

Message Queuing failed to verify digital signature of a message sent to queue PRIVATE=xxxx\xxx. The message was rejected. A negative arrival acknowledgement will be sent if requested by the sender. This event is logged at most once per 600 seconds.

Not massively helpful.  But my messages were being delivered to "System Queues\Transactional dead-letter messages", accompanied with the class "The signature is invalid.".  The Sender tab correctly lists the user sending it, but the message isn't marked as authenticated, and the Hash algorithm is unknown.

The Microsoft documentation on this event suggests one of the following causes:

  • Weak hash function issues
  • Bad user certificate
  • Corruption of the message in transit

Weak hash functions are a result of using an old application, or communicating across-servers using MSMQ, with the downstream server running an older version of MSMQ.  In reality, nobody should be running old MSMQ servers any more as they've all dropped out of support.

My app is built on .NET 4 which does support the latest algorithms for MSMQ, and this was a local queue.  Not a weak hash function.

Corruption of the message in transit doesn't apply either, as the message is only being stored locally and worked fine if authentication was disabled completely.

Bad user certificate being the one left, and marries up with the error in the dead-letter queue.  But when using internal-certificates with MSMQ, there isn't really anything you can do about the certificate in use, apart from refresh it.

MSMQ certificates

In order to use directory-integrated authenticated message queue, a certificate needs to be generated and registered on the server running the source queue.  This has to be done under the credentials that the application will be communicating in.

To create a certificate you need to:

  1. Load Computer Management under the credentials of the application using the Run As... feature (shift right click) after locating the short-cut (search start, right click, open file location).
  2. Right click Message Queuing and go to Properties
  3. Select the User Certificate tab
  4. Click Renew...
  5. Click Register...

Renew will generate a new private/public key pair for that user to use locally with MSMQ.  It will automatically register, but you can do this manually if you want too.  Register takes the public part and writes it into the mSMQSignCertificates attribute in the user's Active Directory object.

You can view which certificates are available to the current user in AD by clicking the View... button.

NB: If you're using IIS, make sure you set the App Pool to load the user profile, otherwise the certificate won't be available to the application.

User certificates cannot be obtained.

But for me, when I clicked the View, or Remove buttons I was being presented with the error:

User certificates cannot be obtained.

Error: There is an internal Active Directory Domain Services error.

Although I could seem to register a certificate successfully, I suspect that this indicated MSMQ might have a problem with retrieving the certificates at runtime and thus cause an invalid signature error.

After much troubleshooting it became apparent that this wasn't a problem on freshly created user accounts.

To resolve the error the following can be done:

  1. Use Active Directory Users and and Computers to locate the effected account (navigate, don't search).
  2. Open properties and select Attribute Editor tab
  3. Find the entries: mSMQDigests and mSMQSignCertificates
  4. Edit them and remove/clear the data
  5. Commit your change
  6. Open the Messaging Queuing console with the effected account on the device that will be creating messages, and navigate to the User Certificate page as above.
  7. Click View - problem should have now gone away and a blank list of certificates shown.  If the error persists you may need to wait for replication.
  8. Click Register to re-register the existing account/computer combined certificate into the Active Directory object.

What causes the entry in Active Directory to become corrupt/unreadable I do not know, and I don't fancy paying for a Microsoft support to find out, now that I have a workaround.

If you have lots of servers, you may need to take a different approach, such as creating a service account-per-server if it continues to be problematic.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

WSL: opensuse proxy settings

Alastair Grant | Friday 20 September 2019

I'm using openSUSE Leap on Windows 10 with WSL (Windows Subsystem for Linux), it provides a great way of accessing useful command line tools without having to install Linux - helpful where the client operating system has to be Windows.

I found one hitch and that's a proxy server being in my way when using the WSL shell.  Fortunately configuring a proxy in openSUSE is very easy, you just need to create a file /etc/sysconfig/proxy with contents similar to:

PROXY_ENABLED="yes"
HTTP_PROXY="http://myproxy:3128"
HTTPS_PROXY="http://myproxy:3128"
FTP_PROXY="http://myproxy:3128"
NO_PROXY="localhost, 127.0.0.1, *.local, *.mydomain"

I though encountered a strange issue when implementing this.  Every time I logged in with a Bash shell, my console would be spammed with the letter "y" for a long time before I'd get in.  And when I did get in, the bash shell didn't have any of the configuration you'd normally expect.

Turns out I made the mistake of including spaces between the key and values in the proxy configuration file, e.g. HTTP_PROXY = "...".  When I went back through and collapsed all the whitespace the issue went away.

 
Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

Disabling DNS over HTTPS at the network level for Firefox

Alastair Grant | Sunday 15 September 2019

Mozilla have recently announced default use of the divisive DNS-Over-HTTPS. The non-issue that is trying to be addressed with DoH is that DNS lookups are unencrypted.

What does this really mean? 

  • Well if you're on a shared network, then other users can snoop the names of sites you're visiting (e.g. google.com, or something more private). 
  • Your government could easily request your ISP to provide a list of sites you're visiting. 
  • Your ISP could be being forced to block certain DNS requests. 
  • Your ISP can also see what DNS queries you are requesting, and then redirect your traffic to their own name-servers to give you a faster response (and then start hijacking non-existent domains to direct you to a holding page of some sort).

DoH moves the DNS query to an encrypted tunnel to a pre-defined DNS resolver.  You'll just have to take the word of Mozilla that this unknown (Cloudfare as it happens) is not logging your requests, blocking anything it's legally required to, or abusing their position by redirecting traffic.

The only hole DoH genuinely seems to plug is the local snooping on a shared network.  But with browsers such as Opera coming with a VPN built-in, plus less reliance on public WiFi as 4G becomes prevalent - I find the need very unconvincing.

By forcing DoH on users, you're forcing the moving of trust from whatever the user currently has selected (or preselected by their ISP) to another organisation.  It doesn't even address the major issue with DNS, and that's man-in-the-middle attacks, or DNS poisoning.  These issues are addressed with DNSSEC, and already established protocol that authenticates responses from the top down.  To address all the points above, you can't rely on DoH, but instead you should look at running a DNS resolver on your local network (or computer) that will verify DNSSEC records.  A bit complicated?  Yes, but not a folly either.

Still, what harm can DoH do?

  1. Should be slower (TLS handshake, followed by a HTTP request is heavier duty then a simple UDP packet)
  2. Will use marginally more bandwidth/data-allowance
  3. Will completely break all access to your local network resource

Point 3 is the one that is going to cause the most annoyance.  If your local network is running a DNS server to manage the names of devices (e.g. any corporate network, and many more advanced home-routers), then you won't be able to type in the name of your local resource into your browser and expect it to find it - because DoH bypasses your setup.

Network level override

Fortunately for us, Mozilla have thought about this and we only need to go through effort ourselves as administrators to ensure everything continues to work.  The simple way to override the change on all client types is to block their "Canary domain": use-application-dns.net, and force an NXDOMAIN response.

Simple enough, but how does one do this?

BIND

It's simple enough if you happen to use this fairly obscure feature... Response Policy Zones.

First off, you need a new zone file along these lines (called "blockedhosts"):

$TTL 4w
@                         IN SOA          localhost.       root.localhost. (1 4w 1d 4w 1m )
                          IN NS           localhost.
use-application-dns.net   IN CNAME        .

Note the hostname we're using here doesn't have a trailing dot.  We're using a placeholder zone name '@', and the domain has a single CNAME record that point to dot.

This is a magic record, it doesn't mean what you might think.  The magic is enabled in your /etc/named.conf

We need a zone definition:

zone "blockedhosts" in {
    type master;
    file "master/blockedhosts";
};

With the file name adjusted as appropriate.  And then the magic, either in the relevant view section, or global options:

response-policy { zone "blockedhosts"; };

Reload named to pick up the changes.  The Response Policy Zone system works by allowing you to re-write requests when being sent back to the client.  Using a dot as the response, means BIND will return our required NXDOMAIN response.

You can also use this approach to black-hole lots of horrible domains, such as malware or advertising domains.  And being a standard zone file, it should be possible to transfer copies of this to your secondary name servers in the usual manner.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

Entries for: September 2019

Previous Next