What is https

I also got asked this … What is https!

Source: http://en.wikipedia.org/wiki/Https

https (Hypertext Transfer Protocol over Secure Socket Layer) is a URI scheme used to indicate a secure HTTP connection. It is syntactically identical to the http:// scheme normally used for accessing resources using HTTP. Using an https: URL indicates that HTTP is to be used, but with a different default TCP port (443) and an additional encryption/authentication layer between the HTTP and TCP. This system was designed by Netscape Communications Corporation to provide authentication and encrypted communication and is widely used on the World Wide Web for security-sensitive communication such as payment transactions and corporate logons.

How It Works
Strictly speaking, https is not a separate protocol, but refers to the combination of a normal HTTP interaction over an encrypted Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks.

An https: URL may specify a TCP port; if it does not, the connection uses port 443 (unsecured HTTP typically uses port 80).

To prepare a web-server for accepting https connections the administrator must create a public key certificate for the web-server. This certificate must be signed by a certificate authority of one form or another, which certifies that the certificate holder is indeed the entity it claims to be. Web browsers are generally distributed with the signing certificates of major certificate authorities, so that they can verify certificates signed by them.

Organizations may also run their own certificate authority, particularly if they are responsible for setting up browsers to access their own sites (for example, sites on a company intranet), as they can trivially add their own signing certificate to those shipped with the browser.

Some sites, especially those operated by hobbyists, use self-signed certificates on public sites. Using these provides protection against simple eavesdropping, but unlike a well-known certificate, preventing a man-in-the-middle attack with a self-signed certificate requires the site to make available some other secure method of verifying the certificate.

The system can also be used for client authentication, in order to restrict access to a Web server to only authorized users. For this, typically the site administrator creates certificates for each user which are loaded into their browser. These normally contain the name and e-mail address of the authorized user, and are automatically checked by the server on each reconnect to verify the user’s identity, potentially without ever entering a password.

 

Exchange 2003 Soft vs. Hard recovery

I got asked this today and just to confirm I was kinda right I thought I would share it! ;-)

Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003
http://technet.microsoft.com/en-us/library/aa997761(EXCHG.65).aspx

As used in Microsoft® Exchange Server 2003, the word recovery must be distinguished from the word restore. Restore is the act of putting database and log files back into place on a server, and recovery is the act of replaying transaction logs into the restored database.

Types of Recovery
There are two forms of recovery:

  • Soft recovery   A transaction log replay process that occurs when a database is re-mounted after an unexpected stop, or when transaction logs are replayed into an offline file copy backup of a database.
  • Hard recovery   A transaction log replay process that occurs after restoring a database from an online backup.

Soft Recovery
In the default soft recovery scenario, an external event unexpectedly stops an Exchange database, but the database and log files remain intact and in place. When the database is mounted again, Exchange reads the checkpoint file and begins to replay the transaction log that is listed as the checkpoint log. If no checkpoint file exists, replay begins with the oldest log file available in the transaction log folder for the storage group.

Exchange writes to the database files completed transactions found in the log file that have not already been written and reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it have been secured to the log files. You do not need to physically undo or back out a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins.

Hard Recovery
Hard recovery must be completed after restoring from online backup. Hard recovery is a log file replay process that is similar to soft recovery, but there are some important differences. In hard recovery:

  • Patch information must be applied to the database during log file replay.
  • The checkpoint file is ignored. Restore.env is used instead of the checkpoint file to determine from which log file recovery should start.
    Exchange 5.5 administrators may be familiar with the Restore in Progress registry key. Restore.env replaces the functionality of that key in Exchange 2000. You can view the contents of the Restore.env file by running the command Eseutil /cm.
  • If the database has been restored to a different path than that from which it was backed up, log file replay succeeds, ignoring the database paths listed in the log files.
  • Restored transaction log files replay first from a temporary folder designated by the administrator before restore. Log files from the normal transaction log folder may also be replayed.
  • Hard recovery does not fail if other databases in the storage group are missing.

Database files (.edb and .stm) restored from an online backup set are restored to the normal paths defined for the database. Restore begins by overwriting existing databases files. If there is any chance that you might need the existing database files in the future, you must move them or back them up before restoring from online backup. Take into consideration that restore of the online backup could fail for any number of reasons. Even if the existing database files cannot be started at the moment, they are probably still repairable, and data could still be salvaged if necessary.

As you begin restoration of an online backup, Exchange prompts you to provide a temporary folder location. The backup program restores transaction log files from the backup set to this location, not to the normal transaction log file path. The backup program also creates the Restore.env file in the temporary folder.

The function of Restore.env in hard recovery is similar to that of the checkpoint file in soft recovery. Restore.env defines the range of transaction log files that should be present in the temporary folder for hard recovery. If you place extra logs in the temporary folder—logs that are outside the range listed in Restore.env—they are not replayed and the recovery process may delete them automatically.

You may have extra log files to replay that are not from an online backup set. In this case, place those logs in the normal transaction logs folder for the storage group and not in the temporary folder. After hard recovery finishes replaying the logs restored from the backup set, the process checks the normal transaction log folder to see if the next log in sequence is available.