Server SSL Support

King Phisher supports serving pages over HTTPS using SSL. This is very helpful for both security as credentials are collected as well as making the site look more legitimate. To enable SSL, the server needs some configuration changes to be made.

Server Configuration Changes

To enable SSL, the server configuration file needs to have the following settings configured:

server:
  addresses:
    - host: 0.0.0.0
      # set the port to 443, the default port for https
      port: 443
      # set ssl to true, by default it is disabled
      ssl: true

  # much lower in the file...

  # specify the path to the certificate file
  ssl_cert: /path/to/ssl.crt
  # specify the path to the SSL key file
  ssl_key: /path/to/ssl.key

SSL can be configured on an per-interface basis using the addresses configuration where it can be enabled or disabled along with the TCP port and IP address. Then later in the configuration file, the default SSL certificate and key are specified using the ssl_cert and ssl_key settings respectively.

Client Configuration Changes

When the client logs in to the King Phisher server, they will need to specify the HTTP port and enable SSL in the login dialog. The HTTP port will be the same value as was specified in the server's configuration file under the address section.

Multiple Host Names

New in version 1.4.0.

Starting in King Phisher version 1.4, multiple SSL certificates can be specified for individual hostnames. This leverages SSL's Server Name Indicator (SNI) extension. This feature requires Python 2.7.9 / 3.4 or newer and for Python to have been compiled with SNI support. Python's SNI support can be checked by running the command:

python3 -c "import ssl; print('Has SNI support: ' + repr(getattr(ssl, 'HAS_SNI', False)))"

To specify additional certificates for hostnames, add an entry into the ssl_hosts server section. This list takes entries with at least a host and ssl_cert setting to define the hostname and SSL certificate file respectively. Please note that a default certificate must still be specified in the ssl_cert field. If the client requests a hostname that does not have a specific certificate or the client does not specify a hostname at all, the default certificate will be presented.

An example configuration:

  # define the default certificate
  ssl_cert: /path/to/default.crt
  ssl_key: /path/to/default.key
  # define additional certificates for specific hostnames
  ssl_hosts:
    - host: king-phisher.com
      ssl_cert: /path/to/king-phisher.com.crt
      ssl_key: /path/to/king-phisher.com.key
      # additional entries can be added

Let's Encrypt Integration

New in version 1.14.0.

Certificates can be issued by King Phisher users using Let's Encrypt and the certbot utility. There are a few prerequisites for this integration to be enabled:

• The letsencrypt section of the server configuration file must be specified.
• The certbot utility must be installed, functional and either in the PATH or defined in the letsencrypt.cerbot_path setting.
  • NOTICE: The certbot utility must be run at least one time from the command line to allow it to prompt the user for configuration and to agree to a series of prompts.
• The server's version of Python must support SNI.
• At least one default certificate must be defined in the server's configuration file to enabled SSL.

With these requirements met, the King Phisher server can be instructed to issue certificates using certbot and then load the SNI configuration, effectively enabling HTTPS for the specified hostname. The operation utilizes the certonly directive with a defined webroot to function without root privileves or restarting the server.

An example configuration:

  letsencrypt:
    # Optionally specify the path to the certbot binary, otherwise search
    # $PATH for it
    #certbot_path: /usr/local/bin/certbot
    # Directory to store Let's Encrypt data to, must be writeable by the King
    # Phisher server process
    data_path: /var/king-phisher/letsencrypt
    # Recursively change the owner of the data path when setuid is enabled
    chown_data_path: true

Let's Encrypt Data

Let's Encrypt stores it's data in three directories by default which are owned by root. Since the King Phisher server drops it's privileges, it needs to store the data in directories which are accessible as defined by the letsencrypt.data_path setting. It's important that this directory tree and all of the files it contains remain owned by the King Phisher server user. These permissions can be automatically set when the King Phisher server start by enabling the letsencrypt.chown_data_path setting.

certbot Flag	Default Path	King Phisher Path
--config-dir	/etc/letsencrypt	$data_path/letsencrypt/etc
--work-dir	/var/lib/letsencrypt	$data_path/letsencrypt/lib
--logs-dir	/var/log/letsencrypt	$data_path/letsencrypt/log

While the King Phisher paths can be symlinked back to the default paths to maintain compatibility with running certbot from the command line, care must be taken to ensure the files are owned by the King Phisher server user.

Additionally, the certbot utility must create a directory within the webroot. To avoid permission issues, use a group and the setgid bit on the webroot as outlined in the File Permissions section of the wiki. This will ensure that the default permissions for new directories retain access for the King Phisher server.