Adjust the score for the serialization vulnerability

* and some additional clarifications
* and some cleanup of wrong rst format

(cherry picked from commit a79bfbf941e5129fcf21d8a9e29d1ae1c55e39a0)

akka-docs/rst/java/cluster-usage.rst

@@ -85,7 +85,7 @@ An actor that uses the cluster extension may look like this:
 The actor registers itself as subscriber of certain cluster events. It receives events corresponding to the current state
 of the cluster when the subscription starts and then it receives events for changes that happen in the cluster.
 
-    The easiest way to run this example yourself is to download `Lightbend Activator <http://www.lightbend.com/platform/getstarted>`_
+The easiest way to run this example yourself is to download `Lightbend Activator <http://www.lightbend.com/platform/getstarted>`_
 and open the tutorial named `Akka Cluster Samples with Java <http://www.lightbend.com/activator/template/akka-sample-cluster-java>`_.
 It contains instructions of how to run the ``SimpleClusterApp``.
 

akka-docs/rst/java/remoting-artery.rst

@@ -264,6 +264,8 @@ It should be protected by network security, such as a firewall. There is current
 so if network security is not considered as enough protection the classic remoting with
 :ref:`TLS and mutual authentication <remote-tls-java>`  should be used.
 
+Best practice is that Akka remoting nodes should only be accessible from the adjacent network.
+
 It is also security best-practice to :ref:`disable the Java serializer <disable-java-serializer-java-artery>` because of 
 its multiple `known attack surfaces <https://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995>`_.
 

akka-docs/rst/java/remoting.rst

@@ -424,6 +424,10 @@ An ``ActorSystem`` should not be exposed via Akka Remote over plain TCP to an un
 It should be protected by network security, such as a firewall. If that is not considered as enough protection
 :ref:`TLS with mutual authentication <remote-tls-java>`  should be enabled.
 
+Best practice is that Akka remoting nodes should only be accessible from the adjacent network. Note that if TLS is 
+enabled with mutual authentication there is still a risk that an attacker can gain access to a valid certificate by
+compromising any node with certificates issued by the same internal PKI tree.
+
 It is also security best-practice to :ref:`disable the Java serializer <disable-java-serializer-java>` because of 
 its multiple `known attack surfaces <https://community.hpe.com/t5/Security-Research/The-perils-of-Java-deserialization/ba-p/6838995>`_.
 
@@ -488,6 +492,9 @@ a certificate from the connecting peer. Without this mode only the client side i
 While Akka is a peer-to-peer technology, each connection between nodes starts out from one side (the "client") towards 
 the other (the "server").
 
+Note that if TLS is enabled with mutual authentication there is still a risk that an attacker can gain access to a valid certificate 
+by compromising any node with certificates issued by the same internal PKI tree.
+
 See also a description of the settings in the :ref:`remote-configuration-scala` section.
 
 .. note::

akka-docs/rst/java/stream/stages-overview.rst

@@ -894,7 +894,7 @@ Similar to ``Flow.fromSinkAndSource`` however couples the termination of these t
 E.g. if the emitted ``Flow`` gets a cancellation, the ``Source`` of course is cancelled,
 however the Sink will also be completed. The table below illustrates the effects in detail:
 
-+-------------------------------------------------+-----------------------------+---------------------------------+
++=================================================+=============================+=================================+
 | Returned Flow                                   | Sink (in)                   | Source (out)                    |
 +=================================================+=============================+=================================+
 | cause: upstream (sink-side) receives completion | effect: receives completion | effect: receives cancel         |