SSL Fax is an internet fax method that is an extension of traditional fax protocol.

After a typical fax call is initiated and during the fax handshaking procedure two fax devices with support for SSL Fax can pass additional handshaking signals between them and thereby initiate a secure internet connection. The fax communication is subsequently conducted over that secure internet connection.

Many, if not most, fax devices today have internet connectivity as well as connectivity to a telephone line. Generally communication speeds on the internet connection will be much faster than on the telephone line. Furthermore, the ubiquity of Voice-over-IP telephone services can make it difficult for reliable use of fax, especially for extremely large documents, color documents, and documents with extremely high resolution. In these cases it may be more reliable to communicate fax data over the internet connection.

Indeed, these security and encryption mechanisms were renamed from "SSL" to "TLS" back in the early 2000s. And, in all truth, SSL Fax always uses TLS. So, why don't we call it "TLS Fax"? The answer is because the "SSL" name has stuck. The name change from "SSL" to "TLS" was a a political compromise between Netscape and Microsoft back in the days of the browser wars. However, the term "SSL" has continued to be used by the industry to mean both SSL and TLS. For example, certificate authorities often market their certificates as "SSL certificates" rather than "TLS certificates". This is done because the name "SSL" has become ubiquitous, and it seems silly to strain over the technicalities of which version of the protocol is being used.

So, because "SSL Fax" will be better-understood than "TLS Fax" would be, we have adopted the "SSL Fax" naming.

Client support for SSL Fax is enabled by default in HylaFAX+ 7.0.0 and later when using a Class 1 or Class 1.0 modem.

Server support for SSL Fax requires use of the Class1SSLFaxInfo modem config option which is assigned a value of "<hostname>:<port>" where "<hostname>" is the publicly accessible internet address for that server, and "<port>" is the publicly accesible port number assigned to SSL Fax for that modem. (Each modem should be assigned different port numbers.) The SSL Fax server also requires a valid PEM file to be created and stored, by default in /var/spool/hylafax/etc/ssl.pem.

ITU T.30 assigns two bits in the DIS and DCS signals which indicate internet fax support. Use of these bits enables support for CSA and TSA frames in the fax protocol. CSA and TSA frames allow fax devices to communicate internet fax support information.

When a properly-configured SSL Fax device sees a DIS or DCS signal indicating support for CSA and TSA frames it will send a CSA or TSA frame (whichever is appropriate) indicating a URL in the format of "ssl://<passcode>@<hostname>:<port>".

When an SSL Fax device sees a CSA or TSA frame indicating an SSL Fax URL as described, then it will make an SSL client connection to the given hostname at the given port. After SSL handshaking completes the given passcode is communicated from the client to the server as a security and identification measure.

After the proper SSL Fax connection is made then the balance of the fax communication is made over the SSL connection rather than the connection on the telephone line.

Yes, SSL Fax is based on standards.

CSA and TSA have been part of the T.30 protocol standard since at least 1999. These features were designed in a way for manufacturers and fax software developers to come up with creative and useful ways for fax systems to switch from modem-oriented telephone lines to internet connections.

T.30 requires that if a fax system indicates internet fax support in DIS or DCS that it must, therefore, have support for handling or ignoring CSA and TSA frames. Therefore, manufacturers and developers were required to collaborate among themselves with respect to the content of the CSA and TSA frames in order for their products to do internet faxing across various makes.

Sadly (and quite unfortunately), this collaboration never really happened before now. Several types of fax devices and software do indicate internet fax support in DIS and DCS, but they do not send CSA or TSA signals, and when they then receive a CSA or TSA signal they immediately fail the fax. (Therefore, they are unable to ignore or handle those signals as required by the fax specification.) Minor violations of the T.30 specification are commonplace, but this seems to be the most blatant and egregious violation of T.30 protocol. Why do they bother setting those DIS and DCS bits at all?

Consequently, SSL Fax requires that both internet fax bits in DIS and DCS be set before CSA and TSA frames are understood to be supported by the remote which would lead us to send CSA or TSA. We, ourselves, must support reception, handling, or ignoring of CSA and TSA frames when either bit is set. (One bit was designed to indicate T.37 support, and the other bit was designed to indicate T.38 support. However, the only requirement imposed by use of either bit is merely to support CSA and TSA frames. Thus, they need not be specific to T.37 and T.38 use.)

SSL Fax is defined here.

Fax developers who have implemented support for Class 1.0 SuperG3/V.34-Fax devices should already be familiar with the communication over the SSL connection. The SSL Fax communication takes its cues from ITU T.31 Amendment 1, ITU T.30, and ITU T.30 Annex F. SSL Fax communication should be readily familiar to most fax developers.

CSA and TSA frames in fax protocol are defined in ITU T.30 5.3.6.2.12.

SSL Fax does not require ECM to be used for documents encoded with MH and MR compression, as SuperG3/V.34-Fax does. (All other data types require ECM per ITU T.30.) However, like SuperG3/V.34-Fax, SSL Fax does not employ the TCF, RTN, RTP, CTC, and CTR frames.

Further use of CSA and TSA frames after SSL Fax negotiation is currently undefined.

If the SSL connection is lost prematurely during a fax session, then fax protocol should revert to the traditional phone line communication for the duration of that fax session until TSA or CSA is resent. Attempts to immediately re-establish the SSL connection may be possible, but is currently undefined.

The SSL Fax server is the party whose CSA or TSA data is used for a connection by the SSL Fax client.

The receiver of a CSA or TSA signal may, for whatever reason, choose to not proceed with an SSL Fax connection. Such reasons may include connectivity issues, compatibility issues, awareness of historical problems, or other matters. Therefore, the sender of a CSA or TSA signal must be prepared for that condition. This will require that the party sending the CSA or TSA signal both listen on an appropriate network socket and also monitor the modem for further signals from the other party.

In order to work within the timing constraints of ITU T.30, the receiver of a CSA or TSA signal must connect to the SSL Fax server very quickly or abandon the attempt if it does not succeed quickly in order to proceed with traditional communication. Usually this should be shorter than 3 seconds.

For added security, the SSL Fax server should only open the network socket and listen for connections at the time that it transmits the CSA or TSA signal until the next response from the other party. Likewise it should close that socket as soon as the SSL Fax session is completed, terminates, or the other party proceeds without establishing an SSL Fax connection.

In the event of a termination of the SSL Fax connection before the fax protocol is completed it is expected that the two parties will resume fax protocol over the traditional modem interface. Therefore, the call on the traditional interface should be left connected throughout the duration of the SSL Fax connection.

An SSL Fax endpoint, whether server or client, may choose to reject the SSL certificate presented by the other party for whatever reason. However, traditional fax does not validate endpoint identity, and validation of an endpoint's certificate within SSL Fax may not necessarily be beneficial. It is expected that most SSL Fax clients will not present a certificate, that most SSL Fax servers will use self-signed certificates, that certificates may be expired, and that the purpose of the certificate is solely to provide for an encrypted communication channel. Therefore, if an SSL Fax application is intended to have the greatest possible compatibility it should refrain from unnecessary certificate validation. However, this is not a requirement, and SSL Fax endpoints may choose to require cerficate validation in whatever methods they determine appropriate. Therefore, applications supporting SSL Fax must be able to revert back to the traditional fax interface without T.30 protocol interruption in the event that the other party rejects and closes their connection.

Yes, absolutely!

Voice gateways are already in the habit of recognizing fax CNG and CED tones, obfuscating NSF signals, and manipulating DIS signals in order to establish an IP connection of some kind (usually T.38). It will usually look something like this:

FAX1---GATEWAY1---IP_NETWORK---GATEWAY2---FAX2

Voice gateways can utilize SSL Fax as a superior alternative to T.38. They would add the internet fax bits to DIS and DCS signals when appropriate, add or remove CSA and TSA signals where appropriate, and otherwise facilitate SSL Fax operation. For example, in the example below neither of the two fax endpoints support SSL Fax. So, the two gateways establish an SSL Fax session between each other.

FAX1---GATEWAY1---IP_NETWORK---GATEWAY2---FAX2
          |________SSL_Fax________|

FAX1---GATEWAY1---IP_NETWORK---GATEWAY2---FAX2
 |____________SSL_Fax_____________|

FAX1---GATEWAY1---IP_NETWORK---GATEWAY2---FAX2
          |____________SSL_Fax_____________|

FAX1---GATEWAY1---IP_NETWORK---GATEWAY2---FAX2
 |_________________SSL_Fax_________________|

In the following example sessions, all data sent over the SSL connection is DLE-encoded. That is to say that DLEs are doubled and the end-of-data is marked by DLE+ETX. Data sent over the SSL connection is indicated in <<this>> manner.

Two-page example using ECM and with TSA accepted.

Sender                                 Receiver
----------------------------------------------------------------------
Dial number
(CNG)                          --->
                                     Detect call, answer
                               <---  (CED)
                               <---  <NSF><CSI><DIS>*
[start SSL server listener]
<TSI><TSA>**<DCS>*<TCF>        --->
[await remote response]***
                               <---  [start client connection]
[SSL connection/handshake]     <-->  [SSL connection/handshake]
                               <---  [SSL Fax passcode]
                               <---  <<CFR>><<DLE>><<ETX>>
[DLE-encoded Phase C over SSL] --->
<<DLE>><<ETX>>                 --->
<<PPS-MPS>><<DLE>><<ETX>>      --->
                               <---  <<MCF>><<DLE>><<ETX>>
[DLE-encoded Phase C over SSL] --->
<<DLE>><<ETX>>                 --->
<<PPS-EOP>><<DLE>><<ETX>>      --->
                               <---  <<MCF>><<DLE>><<ETX>>
<<DCN>><<DLE>><<ETX>>          --->
[await SSL disconnection]
                               <---  [close SSL connection]
hangup modem                         hangup modem

* DIS and DCS include FIF bits 1 and 3 set
** TSA URL of "ssl://<passcode>@<hostname>:<port>"
*** monitor for both SSL connection and V.21 HDLC

Sender                                 Receiver
----------------------------------------------------------------------
Dial number
(CNG)                          --->
                                     Detect call, answer
                               <---  (CED)
                               <---  <NSF><CSI><DIS>*
<TSI><DCS>*<TCF>               --->
                                     [start SSL server listener]
                               <---  <CSA>**<CFR>
                                     [await remote response]***
[start client connection]      --->
[SSL connection/handshake]     <-->  [SSL connection/handshake]
[SSL Fax passcode]             --->
[DLE-encoded Phase C over SSL] --->
<<DLE>><<ETX>>                 --->
<<EOM>><<DLE>><<ETX>>          --->
                               <---  <<MCF>><<DLE>><<ETX>>
<<TSI>><<DCS>>(1)<<DLE><<ETX>> --->
                               <---  <<CFR>><<DLE>><<ETX>>
[DLE-encoded Phase C over SSL] --->
<<DLE>><<ETX>>                 --->
<<EOP>><<DLE>><<ETX>>          --->
                               <---  <<MCF>><<DLE>><<ETX>>
<<DCN>><<DLE>><<ETX>>          --->
                                     [await SSL disconnection]
[close SSL connection]         --->
hangup modem                         hangup modem

* DIS and DCS include FIF bits 1 and 3 set
** CSA URL of "ssl://<passcode>@<hostname>:<port>"
*** monitor for both SSL connection and V.17/V.29/V.27ter
(1) TCF is not used when SSL Fax is in use

Sender                                 Receiver
----------------------------------------------------------------------
Dial number
(CNG)                          --->
                                     Detect call, answer
                               <---  (CED)
                               <---  <NSF><CSI><DIS>*
[start SSL server listener]
<TSI><TSA><DCS>*<TCF>          --->
[await remote response]***
                                     [start SSL server listener]
                               <---  <CSA>**<CFR>
                                     [await remote response]***
[stop SSL server listener]
[start client connection]      --->
[SSL connection/handshake]     <-->  [SSL connection/handshake]
[SSL Fax passcode]             --->
[DLE-encoded Phase C over SSL] --->
<<DLE>><<ETX>>                 --->
<<PPS-MPS>><<DLE>><<ETX>>      --->
                               <---  <<RNR>><<DLE>><<ETX>>
<<RR>><<DLE>><<ETX>>           --->
                               <---  <<RNR>><<DLE>><<ETX>>
<<RR>><<DLE>><<ETX>>           --->
                               <---  <<MCF>><<DLE>><<ETX>>
[DLE-encoded Phase C over SSL] --->
<<DLE>><<ETX>>                 --->
<<PPS-EOP>><<DLE>><<ETX>>      --->
                               <---  <<RNR>><<DLE>><<ETX>>
<<RR>><<DLE>><<ETX>>           --->
                               <---  <<RNR>><<DLE>><<ETX>>
<<RR>><<DLE>><<ETX>>           --->
                               <---  <<MCF>><<DLE>><<ETX>>
<<DCN>><<DLE>><<ETX>>          --->
                                     [await SSL disconnection]
[close SSL connection]         --->
hangup modem                         hangup modem

* DIS and DCS include FIF bits 1 and 3 set
** CSA URL of "ssl://<passcode>@<hostname>:<port>"
*** monitor for both SSL connection and V.21 HDLC or V.17/V.29/V.27ter (as appropriate)