diff --git a/source/ftpserver-project/releasing.md b/source/ftpserver-project/releasing.md
index da9eae8..eb5245b 100644
--- a/source/ftpserver-project/releasing.md
+++ b/source/ftpserver-project/releasing.md
@@ -268,10 +268,10 @@
 <Your PGP passphrase>
 
 -n Signing: ./apache-ftpserver-<version>-bin.tar.bz2 ... 
-  - Generated './apache-ftpserver-<version>-bin.tar.bz2.sha1'
+  - Generated './apache-ftpserver-<version>-bin.tar.bz2.sha512'
   - Generated './apache-ftpserver-<version>-bin.tar.bz2.asc'
 -n Signing: ./apache-ftpserver-<version>-bin.tar.gz ... 
-  - Generated './apache-ftpserver-<version>-bin.tar.gz.sha1'
+  - Generated './apache-ftpserver-<version>-bin.tar.gz.sha512'
   - Generated './apache-ftpserver-<version>-bin.tar.gz.asc'
 ...
 ```
@@ -298,17 +298,8 @@
 
   echo -n "Signing: $FILE ... "
 
-  # SHA-256
-  if [ ! -f "$FILE.sha256" ];
-  then
-      gpg -v --default-key "$DEFAULT_KEY" --print-md SHA256 "$FILE" > "$FILE".sha256
-      echo "  - Generated '$FILE.sha256'"
-  else
-      echo "  - Skipped '$FILE.sha256' (file already existing)"
-  fi
-
   # SHA-512
-  if [ ! -f "$FILE.shacw512256" ];
+  if [ ! -f "$FILE.sha512" ];
   then
       gpg -v --default-key "$DEFAULT_KEY" --print-md SHA512 "$FILE" > "$FILE".sha512
       echo "  - Generated '$FILE.sha512'"
diff --git a/source/mina-project/developer-guide.md b/source/mina-project/developer-guide.md
index d92d57c..be3064e 100644
--- a/source/mina-project/developer-guide.md
+++ b/source/mina-project/developer-guide.md
@@ -185,7 +185,7 @@
 Answer to maven questions :
 
 ```text
-"What is the release version for "Apache MINA"? (org.apache.mina:mina-parent) 2.0.7-<version>: :" 
+"What is the release version for "Apache MINA"? (org.apache.mina:mina-parent) <version>: :" 
 <either use the default version as suggested, or type in the version you@qot;d like to be used>
 [..]
 ```
@@ -197,6 +197,19 @@
     
     Make sure the change made by the release plugin is correct! (pom.xml, tags created)
 </div>
+
+<div class="info" markdown="1">
+    <strong>In case of a problem...</strong><br>
+    
+    It's frequent that the dry-run fails, typically when you have some Javadoc issues (with Java 8, the compiler is really picky about wrong HTML tags or missing parameters).
+
+    You can rollback the release with the command:
+
+    $ mvn -Pserial,apache-release -DdryRun=true release:rollback
+
+    You should be back on your feet. 
+</div>
+
     
 ### Step 3 : Processing with the real release
 
@@ -223,7 +236,7 @@
 
 ### Step 4 : perform the release
 
-The last step before launching a vote is to push the potential release to Nexus so that every user can test the created packages. Perform the following actions (note that we have to run a build first for teh javadoc to be correctly generated...) :
+The last step before launching a vote is to push the potential release to Nexus so that every user can test the created packages. Perform the following actions (note that we have to run a build first for the javadoc to be correctly generated...) :
 
 ```bash
 $ mvn clean install -Pserial -DskipTests
@@ -348,10 +361,10 @@
 <Your PGP passphrase>
 
 -n Signing: ./apache-mina-2.0.9-bin.tar.bz2 ... 
-  - Generated './apache-mina-2.0.9-bin.tar.bz2.sha1'
+  - Generated './apache-mina-2.0.9-bin.tar.bz2.sha512'
   - Generated './apache-mina-2.0.9-bin.tar.bz2.asc'
 -n Signing: ./apache-mina-2.0.9-bin.tar.gz ... 
-  - Generated './apache-mina-2.0.9-bin.tar.gz.sha1'
+  - Generated './apache-mina-2.0.9-bin.tar.gz.sha512'
   - Generated './apache-mina-2.0.9-bin.tar.gz.asc'
 ...
 ```
@@ -378,17 +391,8 @@
 
   echo -n "Signing: $FILE ... "
 
-  # SHA-256
-  if [ ! -f "$FILE.sha256" ];
-  then
-      gpg -v --default-key "$DEFAULT_KEY" --print-md SHA256 "$FILE" > "$FILE".sha256
-      echo "  - Generated '$FILE.sha256'"
-  else
-      echo "  - Skipped '$FILE.sha256' (file already existing)"
-  fi
-
   # SHA-512
-  if [ ! -f "$FILE.shacw512256" ];
+  if [ ! -f "$FILE.sha512" ];
   then
       gpg -v --default-key "$DEFAULT_KEY" --print-md SHA512 "$FILE" > "$FILE".sha512
       echo "  - Generated '$FILE.sha512'"
diff --git a/source/mina-project/userguide/ch5-filters/ch5.19-ssl-filter.md b/source/mina-project/userguide/ch5-filters/ch5.19-ssl-filter.md
index ae7fcc9..931007c 100644
--- a/source/mina-project/userguide/ch5-filters/ch5.19-ssl-filter.md
+++ b/source/mina-project/userguide/ch5-filters/ch5.19-ssl-filter.md
@@ -11,4 +11,86 @@
 
 # 5.19 - SSL/TLS Filter
 
-TBD...
+This is a critical part of any serious network application: securing the communication between the client and the server.
+
+In **MINA**, we do that with the **SslFilter**. The idea is to add this _Filter_ in the chain and it will deal with the _Handshake_ negociation, and the following encrypting and uncrypting of the data.
+
+## How it works
+
+The thing to remember is that the **TLS** protocol works in two steps:
+* First there is a negociation part (the _Handshake_)
+* Then once the _Handshake_ is completed, all the data will be encrypted before being sent.
+
+We just have to add the filter in the chain like this:
+
+```
+   ...
+   SslFilter sslFilter = new SslFilter(sslContext);
+   DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
+   chain.addFirst("sslFilter", sslFilter);
+   ...
+
+```
+
+The _chain_ is the instance of **IoFilterChainBuilder** class that is associated with either the _Connector_ or the _Acceptor_ instances (wether we are using a client or a server).
+
+<div class="note" markdown="1">
+Usually the **SSLFilyter** is always set at the first position in the chain. The rationnal is that it will receive and send encrypted data, so there is little use of having a functionnal filter between the head of the chain and the **SslFilter**. However, if such a filter is to be used, make sure it does not interfere with the data being exchanged with the remote peer.
+</div>
+
+The missing part here is the _sslContext_ which has to be defined. It's an instande of the **SSLContext** class, where you define a **TrustManager**, a **KeyManager** and a **Securerandom**.
+
+<div class="note" markdown="1">
+	This part is strandard Java security. You'll find plenty of pages on internet explaining you to set up a proper _SSLContext_ instance.
+</div>
+
+### Handshake
+
+The **Handshake** is automatically initiated by the server when the connection is created. The **SslFilter** has a _onPostAdd_ method which create a **SSLEngine** instance based on the provided **SSLContext**.
+
+It sets the **SSLEngine** characteristics:
+* Whether the client authentication is requested or required (_needClientAuth_ and _wantClientAuth_ flags)
+* Sets the enabled cipher suites
+* Sets the enabled protocols
+
+Last, not least, the **CLIENT_HELLO** **TLS** request is sent by the client side, the server is waiting for it. There starts a serie of **TLS** messages exchanged between the cleint and the server, at teh end of which the session is secured, and data can be exchanged encrypted.
+
+What is important to note here is that during the **Handshake** exchanges, no application data can be sent, and the **SslFilter** is handling the whole process, before returning the hand to the application.
+
+### Session secured
+
+The application is informed that the session is secured:
+
+* In **MINA** 2.0.X, the **SslFilterMessage** message is sent and can be processed in the **IoHandler.messageReived** handler.
+* In **MINA** 2.1.X and 2.2.X, the **IoHandler** interface exposes an _event_ handler that is used by the **SslFilter** to inform the application that the session is secured, by emmiting a **SslEvent.SECURED** event.
+
+It's clear that the way **MINA** 2.1.X and 2.2.X signal that the session is secured is way simpler.
+
+### StartTLS use case
+
+Some protocols, like **LDAP**, **FTP**, **XMPP**, **NNTP**, **SMTP**, can be used without encryption, but allow some encryption to be set by using a specific command. When this command is issued, the **TLS** layer is added to an already connected session, without reestablishing a new session.
+
+That is what the **startTLS** command is used for that purpose. Here are a list of existing protocols that use this mechanism:
+
+* [**IMAP, POP3 and ACAP**](https://datatracker.ietf.org/doc/html/rfc2595)
+* [**SMTP**](https://datatracker.ietf.org/doc/html/rfc3207)
+* [**XMPP**](https://datatracker.ietf.org/doc/html/rfc6120)
+* [**NNTP**](https://datatracker.ietf.org/doc/html/rfc4642)
+* [**LDAP**](https://datatracker.ietf.org/doc/html/rfc4513)
+
+The way it works is that at some point of a clear text established connection, the client sends a **STARTLS** command, which forces the **TLS** handshake to start to establish a secured connection. When the secured connection is established, the client and the server exchanges will be encrypted.
+
+Now, that is a bit tricky to implement, because both the client *and* the server must block the exchange of messages during the establishement of the **TLS** session. As the client is the initiator of the command, it's easy, but on the server side, we must pass a response to the original command **in clear text** informing the client that the command has been received and processed.
+
+```
+(C) The client sends a **StartTLS** command
+(S) The server receives the command, initialize the **TLS** layer, and send back a response to the client, bypassing the **TLS** layer.
+(C) The client received the server response to the command, and setup the **TLS** layer, and initiates the **TLS** handshake
+(S/C) The Handshake is processed
+(S/C) The session is secured on both side
+(S/C) at this point, every message exchanged are encrypted.
+```
+
+
+
+