better explaininh nmap greppable, some RFCs

Man-page.md

@@ -68,9 +68,21 @@ Options are either short or long options. All options requiring a value can be c
 `--file <fname>` is the mass testing option. Per default it implicitly turns on `--warnings batch`.
 In its first incarnation the mass testing option reads command lines from `<fname>`. `<fname>` consists of command lines of testssl, one line per instance. Comments after `#` are ignored, `EOF` signals the end of <fname> any subsequent lines will be ignored too. You can also supply additional options which will be inherited to each child, e.g.  When invoking `testssl.sh --wide --log --file <fname>` . Each single line in `<fname>` is parsed upon execution. If there's a conflicting option and serial mass testing option is being performed the check will be aborted at the time it occurs and depending on the output option potentially leaving you with an output file without footer. In parallel mode the mileage varies.
 
-Alternatively `<fname>` can be in `nmap`'s grep(p)able output format (`-oG`). Only open ports will be considered. Multiple ports per line are allowed. The ports can be different and will be tested by testssl.sh according to common practice in the internet, .i.e. if nmap shows in its output an open port 25, automatically `-t smtp` will be added before the URI whereas port 465 will be treated as a plain TLS/SSL port, not requiring an STARTTLS SMTP handshake upfront.
+Alternatively `<fname>` can be in `nmap`'s grep(p)able output format (`-oG`). Only open ports will be considered. Multiple ports per line are allowed. The ports can be different and will be tested by testssl.sh according to common practice in the internet, .i.e. if nmap shows in its output an open port 25, automatically `-t smtp` will be added before the URI whereas port 465 will be treated as a plain TLS/SSL port, not requiring an STARTTLS SMTP handshake upfront. This is done by an internal table which correlates nmap's open port to the STARTTLS/plain text decision from testssl.sh.
 
-The nmap output always returns IP addresses and -- only if there's a PTR DNS record available -- a hostname.                                    As it is not checked by nmap whether the hostname matches the IP (A or AAAA record), testssl.sh does this for you. If the A record of the hostname matches the IP address, the hostname is used and not the IP address. As stated above, checks against an IP address might not hit the vhost you maybe were aiming at.
+The nmap output always returns IP addresses and -- only if there's a PTR DNS record available -- a hostname. As it is not checked by nmap whether the hostname matches the IP (A or AAAA record), testssl.sh does this for you. If the A record of the hostname matches the IP address, the hostname is used and not the IP address. Watch out as stated above checks against an IP address might not hit the vhost you maybe were aiming at.
+
+A typical internal conversion from nmap's grep(p)able format could look like:
+
+```
+10.10.12.16:443
+10.10.12.16:1443
+-t smtp host.example.com:25
+host.example.com:443
+host.example.com:631
+-t ftp 10.10.12.11:21
+10.10.12.11:8443
+```
 
 `--mode <serial|parallel>`. Mass testing to be done serial (default) or parallel (`--parallel `is shortcut for the latter, `--serial` is the opposite option). Per default mass testing is being run in serial mode, i.e. one line after the other is processed and invoked. The variable `MASS_TESTING_MODE` can be defined to be either equal `serial` or `parallel`.
 
@@ -133,13 +145,29 @@ Any single option supplied prevents testssl.sh from doing a default run. It just
 `-S, --server_defaults`         displays information from the server hello(s): available TLS extensions, TLS ticket + session information/capabilities and several certificate info including revocation info (CRL, OCSP, OCSP stapling/must staple), Certification Authority Authorization (CAA) record and: trust (CN, SAN, Chain of trust, expiration of certificate). For trust chain check there are 4 certificate stores provided (see section `FILES` below). If the trust is confirmed or not confirmed and the same in all four vertificate stores there will be only one line of output with the appropriate result. If there are different results, each store is listed and for the one where there's no trust there's an indication what the failure is. Additional certificate stores for e.g. an intranet CA an be put into __etc/__ with the extension __pem__. In that case there will be a complaint about a missing trust with the other stores, in the opposite case -- i.e. if trust will be checked against hosts having a certificate issued by a different CA -- there will be a complaint by a missing trust in this additional store.
 If the server provides no matching record in Subject Alternative Name (SAN) but in Common Name (CN), it will be clearly indicated as this is deprecated. Possible fingerprinting is possible by the results in TLS clock skew: Only a few servers nowadays still have and TLS/SSL implementation which returns the local clock `gmt_unix_time` (e.g. IIS, openssl < 1.0.1f). In addition to the HTTP date you could derive that there are different hosts where your TLS and your HTTP request ended -- if the time deltas differ significantly. Also multiple server certificates are being checked for as well as the certificate reply to a non-SNI (Server Name Indication) client hello to the IP address.
 
-`-y, --spdy, --npn`             checks for SPDY/NPN
+`-x <pattern>, --single-cipher <pattern>` tests matched `<pattern>` of ciphers against a server. Patterns are similar to `-V <pattern> , --local <pattern>`
 
-`-x <pattern>, --single-cipher <pattern>` tests matched `<pattern>` of ciphers (if `<pattern>` not a number: word match)
+`-h, --header, --headers`       if the service is HTTP (either by detection or by enforcing via `--assume-http` it tests several HTTP headers like
 
-`-U, --vulnerable`              tests all vulnerabilities
+* HTTP Strict Transport Security (HSTS)
+* HTTP Public Key Pinning (HPKP)
+* Server banner
+* Application banner (PHP, RoR, OWA, SharePoint, Wordpress, etc)
+* Reverse proxy headers
+* Linux or other Unix vendor headers
+* Web server module
+* IPv4 address
+* Cookie (including Secure/HTTPOnly flags)
+* Security headers (X-Frame-Options, X-XSS-Protection, ..., CSP headers)
 
-`-H, --heartbleed`              tests for heartbleed vulnerability
+
+### VULNERABILITIES
+
+(counter)
+
+`-U, --vulnerable`              Just tests all (following) vulnerabilities. The environment variable `VULN_THRESHLD` determines after which value a separate headline for each vulnerability is being displayed. Default is `1` which means if you check for two vulnerabilities, only the general headline for vulnerabilities section is displayed -- in addition to the vulnerability and the ersult.
+
+`-H, --heartbleed`              tests for Heartbleed vulnerability
 
 `-I, --ccs, --ccs-injection`    tests for CCS injection vulnerability
 
@@ -165,7 +193,6 @@ If the server provides no matching record in Subject Alternative Name (SAN) but
 
 `-4, --rc4, --appelbaum`        which RC4 ciphers are being offered?
 
-`-h, --header, --headers`       tests HSTS, HPKP, server/app banner, security headers, cookie, reverse proxy, IPv4 address
 
 
 ### OUTPUT OPTIONS
@@ -242,9 +269,25 @@ does the same on the plain text IMAP port. Please note that for plain TLS-encryp
 **253**  no SSL/TLS enabled server / OPENSSL too old / couldn\'t connect to proxy / couldn't connect via STARTTLS
 **254**  no OPENSSL found or not exexutable / no IPv4 address could be determined / illegal STARTTLS protocol supplied / supplied file name not readable
 
-### RFCs
+### RFCs and other standards
+
+* RFC 2246: The TLS Protocol Version 1.0
+* RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1
+* RFC 4366: 
+* RFC 4492: 
+* RFC 5077: Transport Layer Security (TLS) Session Resumption
+* RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
+* RFC 5321: Simple Mail Transfer Protocol
+* RFC 5746:
+* RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0
+* RFC 6125: Domain-Based Application Service Identity [..]
+* RFC 6797: HTTP Strict Transport Security (HSTS)
+* RFC 7685: 
+* RFC 7469: Public Key Pinning Extension for HTTP (HPKP)
+* RFC 7507:
+* RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security
+* W3C CSP: Content Security Policy Level 1-3
 
-fixme
 
 ### FILES