<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://wiki.cas.mcmaster.ca/skins/common/feed.css?207"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://wiki.cas.mcmaster.ca/index.php?feed=atom&amp;target=KathyBennett&amp;title=Special%3AContributions</id>
		<title>Computing and Software Wiki - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://wiki.cas.mcmaster.ca/index.php?feed=atom&amp;target=KathyBennett&amp;title=Special%3AContributions"/>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Special:Contributions/KathyBennett"/>
		<updated>2026-04-06T21:19:05Z</updated>
		<subtitle>From Computing and Software Wiki</subtitle>
		<generator>MediaWiki 1.15.1</generator>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Hypertext_Transfer_Protocol_over_Secure_Socket_Layer_(HTTPS)</id>
		<title>Hypertext Transfer Protocol over Secure Socket Layer (HTTPS)</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Hypertext_Transfer_Protocol_over_Secure_Socket_Layer_(HTTPS)"/>
				<updated>2009-10-06T19:42:47Z</updated>
		
		<summary type="html">&lt;p&gt;KathyBennett:&amp;#32;/* History and development */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Image:weblooking.jpg|thumb|300px|right]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Abstract''' &lt;br /&gt;
&lt;br /&gt;
The ''secure hypertext transfer protocol'' (HTTPS) is a communications protocol designed to transfer encrypted information between computers over the World Wide Web. HTTPS is http using a '''Secure Socket Layer (SSL)'''. It connections are often used for payment transactions on the Web and for sensitive transactions in corporate information systems. It is relative simple and efficiency way to transfer information through '''HTTP'''. Since its own property, it is bound by Web browser software and '''Secure Sockets Layer (SSL)'''. Therefore it inherits their shortcoming. On the other side, with those two kinds of technology developing, HTTPS also extend itself to new solution to face varied application problem.&lt;br /&gt;
&lt;br /&gt;
HTTPS has also been known as &amp;quot;Hypertext Transfer Protocol over Secure Socket Layer&amp;quot;, but now HTTPS may be secured by the '''Transport Layer Security (TLS)''' instead of '''Secure Sockets Layer (SSL)''' protocol.&lt;br /&gt;
&lt;br /&gt;
To '''invoke''' HTTPS, one replaces &amp;quot;http://&amp;quot; with &amp;quot;https://&amp;quot; in the URI, or Web address.You can tell if the web site uses this security by looking for the HTTPS in front of the address and the '''&amp;quot;lock&amp;quot;''' icon, which may appear in different locations depending on your choice of web browser:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== History and development ==&lt;br /&gt;
According to many [http://www.research-service.com/custom-research-paper.html research papers] that they make, early research efforts toward transport layer security included the Secure Network Programming (SNP) API, which in 1993 explored the approach of having a secure transport layer API closely resembling sockets, to facilitate retrofitting preexisting network applications with security measures. The SNP project received the 2004 ACM Software System Award.'''[5]'''&lt;br /&gt;
&lt;br /&gt;
The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 was released in February 1995 but &amp;quot;contained a number of security flaws which ultimately led to the design of SSL version 3.0&amp;quot;, which was released in 1996 (Rescorla 2001). This later served as the basis for TLS version 1.0, an Internet Engineering Task Force (IETF) standard protocol first defined in RFC 2246 in January 1999. '''[5]'''Visa, MasterCard, American Express and many leading financial institutions have endorsed SSL for commerce over the Internet.&lt;br /&gt;
&lt;br /&gt;
SSL operates in modular fashion. It is extensible by design, with support for forward and backward compatibility and negotiation between peers.&lt;br /&gt;
&lt;br /&gt;
== Applications ==&lt;br /&gt;
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, provided that adequate cipher suites are used and that the server certificate is verified and trusted. RFC 2818 &lt;br /&gt;
&lt;br /&gt;
An https: URL may specify a TCP port. If it does not, the connection uses port 443 (unsecured HTTP typically uses port 80).&lt;br /&gt;
&lt;br /&gt;
An increasing number of client and server products support TLS natively, but many still lack support. As an alternative, users may wish to use standalone TLS products like Stunnel. Wrappers such as Stunnel rely on being able to obtain a TLS connection immediately, by simply connecting to a separate port reserved for the purpose. For example, by default the TCP port for HTTPS is 443, to distinguish it from HTTP on port 80. RFC 2818&lt;br /&gt;
&lt;br /&gt;
[[Image:Example.jpg|thumb|300px|right]]&lt;br /&gt;
&lt;br /&gt;
== How it works ==&lt;br /&gt;
&lt;br /&gt;
A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.&lt;br /&gt;
&lt;br /&gt;
The '''handshake''' begins when a client connects to a TLS-enabled server requesting a secure connection, and presents a list of supported ciphers and hash functions.From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA), and the server's public encryption key. RFC 2660 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Client Behavior ===&lt;br /&gt;
&lt;br /&gt;
Because HTTP uses connection closure to signal end of server data,client implementations MUST treat any premature closes as errors and&lt;br /&gt;
the data received as potentially truncated.RFC 2616   While in some cases the HTTP protocol allows the client to find out whether truncation took place so that, if it received the complete reply, it may tolerate such errors following the principle to &amp;quot;[be] strict when sending and tolerant when receiving&amp;quot; RFC 4347, often truncation does not show in the HTTP protocol data; two cases in particular deserve special note:&lt;br /&gt;
&lt;br /&gt;
* A HTTP response without a Content-Length header. Since data length in this situation is signalled by connection close a premature close generated by the server cannot be distinguished from a spurious close generated by an attacker.'''[1]'''&lt;br /&gt;
&lt;br /&gt;
* A HTTP response with a valid Content-Length header closed before all data has been read. Because TLS does not provide document oriented protection, it is impossible to determine whether the server has miscomputed the Content-Length or an attacker has truncated the connection.RFC 4366&lt;br /&gt;
&lt;br /&gt;
* There is one exception to the above rule. When encountering a premature close, a client SHOULD treat as completed all requests for  which it has received as much data as specified in the Content-Length header.RFC 4367&lt;br /&gt;
&lt;br /&gt;
* A client detecting an incomplete close SHOULD recover gracefully.  It MAY resume a TLS session closed in this fashion.&lt;br /&gt;
&lt;br /&gt;
* Clients MUST send a closure alert before closing the connection.Clients which are unprepared to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side.RFC 2660&lt;br /&gt;
&lt;br /&gt;
===Server Behavior===&lt;br /&gt;
Permits an HTTP client to close the connection at any time,and requires servers to recover gracefully.  In particular, servers SHOULD be prepared to receive an incomplete close from the client,since the client can often determine when the end of server data is.Servers SHOULD be willing to resume TLS sessions closed in this fashion.&lt;br /&gt;
&lt;br /&gt;
This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes. RFC 2616 &lt;br /&gt;
&lt;br /&gt;
If any one of the above steps fails, the TLS handshake fails, and the connection is not created.&lt;br /&gt;
&lt;br /&gt;
== Limitations ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The level of protection depends on the correctness of the implementation by the Web browser and the server software and the actual cryptographic algorithms supported.&lt;br /&gt;
&lt;br /&gt;
Also, HTTPS is unsecured when applied on publicly-available static content. The entire site can be indexed using a Web crawler, and the URI of the encrypted resource can be inferred by knowing only the intercepted request/response size.'''[1]''' This allows an attacker to have access to the plaintext (the publicly-available static content), and the encrypted text (the encrypted version of the static content).&lt;br /&gt;
&lt;br /&gt;
Because SSL operates below HTTP and has no knowledge of higher-level protocols, SSL servers can only strictly present one certificate for a particular IP/port combination.'''[1]''' This means that, in most cases, it is not feasible to use name-based virtual hosting with HTTPS. RFC-3546 TLS Extensions describes a solution called Server Name Indication (SNI), although many older browsers don't support this extension. Support for SNI is available since Firefox 2.0, Opera 8, Mozilla 1.8, and Internet Explorer 7 on Windows Vista.'''[2][3]'''&lt;br /&gt;
&lt;br /&gt;
With the newer Internet Explorer 7 browser, Microsoft has increased the warnings sent when certificates are not registered. Whereas previously only a &amp;quot;security advice&amp;quot; pop-up appeared (which differentiated between name, source, and run time of the certificate), now a warning is displayed across the entire window, which recommends not using the Web site. Therefore, a certificate that is not registered in the browser is not usable for mass applications. Certificates that are registered in the root chains cost between US$10 and $1,200 per year.&lt;br /&gt;
&lt;br /&gt;
===Browser implementations===&lt;br /&gt;
Mozilla Firefox supports TLS 1.0 since version 2. &lt;br /&gt;
&lt;br /&gt;
The Internet Explorer 8 in Windows 7 and Windows Server 2008 R2 supports TLS 1.2. &lt;br /&gt;
&lt;br /&gt;
As of Presto (layout engine)Presto 2.2, featured in Opera (web browser)|Opera 10, Opera supports TLS 1.2&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
[[Transport Layer Security]]&lt;br /&gt;
&lt;br /&gt;
== External Links ==&lt;br /&gt;
'''The current approved version is 1.2, which is specified in:'''&lt;br /&gt;
* RFC 2660: &amp;quot;The Secure HyperText Transfer Protocol&amp;quot;.&lt;br /&gt;
* RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.&lt;br /&gt;
&lt;br /&gt;
'''The current standard obsoletes these former versions:'''&lt;br /&gt;
* RFC 2246: “The TLS Protocol Version 1.0”.&lt;br /&gt;
* RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.&lt;br /&gt;
&lt;br /&gt;
'''Other [[Request for comments|RFC]]s subsequently extended TLS, including:'''&lt;br /&gt;
* RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same ''well known'' port (in this case, http: at 80 rather than https: at 443).&lt;br /&gt;
* RFC 2818: “HTTP Over TLS”, distinguishes secured traffic from insecure traffic by the use of a different 'server port'.&lt;br /&gt;
* RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for negotiating protocol extensions during session initialisation and defines some extensions. Made obsolete by RFC 4366.&lt;br /&gt;
* RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the framework for compression methods and the [[DEFLATE]] compression method.&lt;br /&gt;
* RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.&lt;br /&gt;
* RFC 4132: “Addition of [[Camellia (cipher)|Camellia]] Cipher Suites to Transport Layer Security (TLS)”.&lt;br /&gt;
* RFC 4279: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds three sets of new ciphersuites for the TLS protocol to support authentication based on pre-shared keys.&lt;br /&gt;
* RFC 4347: “[[Datagram Transport Layer Security]]” specifies a TLS variant that works over datagram protocols (such as UDP).&lt;br /&gt;
* RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of specific extensions, and a generic extension mechanism.&lt;br /&gt;
* RFC 4492: “[[Elliptic Curve Cryptography]] (ECC) Cipher Suites for Transport Layer Security (TLS)”.&lt;br /&gt;
* RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.&lt;br /&gt;
* RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
# Named-based SSL virtual hosts: how to tackle the problem, SWITCH.&lt;br /&gt;
# Mozilla (2008-08-06/). &amp;quot;Security in Firefox 2&amp;quot;. https://developer.mozilla.org/en/Security_in_Firefox_2. &lt;br /&gt;
# Microsoft (2009-02-27/). &amp;quot;MS-TLSP Appendix A&amp;quot;. http://msdn.microsoft.com/en-us/library/dd208005%28PROT.13%29.aspx.&lt;br /&gt;
# OpenSSL Contributions http://www.openssl.org/contrib/&lt;br /&gt;
#  Association for Computing Machinery, &amp;quot;ACM: Press Release, March 15, 2005&amp;quot;, campus.acm.org, accessed December 26, 2007. (English version).&lt;br /&gt;
--[[User:Maoy5|Maoy5]] 22:57, 12 April 2009 (EDT)&lt;/div&gt;</summary>
		<author><name>KathyBennett</name></author>	</entry>

	<entry>
		<id>http://wiki.cas.mcmaster.ca/index.php/Open_source_IDS:_Prelude_and_Snort</id>
		<title>Open source IDS: Prelude and Snort</title>
		<link rel="alternate" type="text/html" href="http://wiki.cas.mcmaster.ca/index.php/Open_source_IDS:_Prelude_and_Snort"/>
				<updated>2009-10-06T19:40:32Z</updated>
		
		<summary type="html">&lt;p&gt;KathyBennett:&amp;#32;/* snort */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== [[snort]] ==&lt;br /&gt;
&lt;br /&gt;
Snort is a free and open source Network Intrusion prevention system (NIPS) and network intrusion detection system (NIDS) utilizing a rule-driven language, which combines the benefits of signature, protocol and anomaly based inspection methods. With millions of downloads to date, Snort is the most widely deployed intrusion detection and prevention technology worldwide and has become the de facto standard for the industry. It is capable of performing packet logging and real-time traffic analysis on IP networks. Snort was written by Martin Roesch and is now developed and research and put to [http://www.research-service.com/custom-research-paper.html research papers] by Sourcefire, of which Roesch is the founder and CTO. Integrated enterprise versions with purpose built hardware and commercial support services are sold by Sourcefire.&lt;br /&gt;
Snort performs protocol analysis, content searching/matching, and is commonly used to actively block or passively detect a variety of attacks and probes, such as buffer overflows, stealth port scans, web application attacks, SMB probes, and OS fingerprinting attempts, amongst other features. The software is mostly used for intrusion prevention purposes, by dropping attacks as they are taking place. Snort™ can be combined with other software such as SnortSnarf, sguil, OSSIM, and the Basic Analysis and Security Engine (BASE) to provide a visual representation of intrusion data. With patches for the Snort source from Bleeding Edge Threats, support for packet stream antivirus scanning with ClamAV and network abnormality with SPADE in network layers 3 and 4 is possible with historical observation. ( These patches seem to be no longer maintained )&lt;br /&gt;
Sourcefire became public in 2007 (NASD:FIRE) after Check Point's attempt to acquire it in 2005 fell through as both companies mutually withdrew from the acquisition process.&lt;br /&gt;
Sourcefire recently purchased the ClamAV open source project.&lt;br /&gt;
&lt;br /&gt;
http://www.snort.org/&lt;br /&gt;
&lt;br /&gt;
== [[Prelude-IDS, open source hybrid IDS framework]] == &lt;br /&gt;
&lt;br /&gt;
Prelude is an open source Unix based Network-Based Intrusion Detection System. It is released under the GPL license, and is similar to Snort.&lt;br /&gt;
&lt;br /&gt;
Prelude is an Hybrid IDS framework, that is, it is a product that enable all available security application, be it opensource or proprietary, to report to a centralized system. In order to achieve this task, Prelude relies on the IDMEF (Intrusion Detection Message Exchange Format) IETF standard, that enables different kinds of sensors to generate events using an unified language.&lt;br /&gt;
&lt;br /&gt;
Prelude benefits from its ability to find traces of malicious activity from different sensors (Snort, honeyd, Nessus Vulnerability Scanner, Samhain, over 30 types of systems logs, and many others) in order to better verify an attack and in the end to perform automatic correlation between the various events.&lt;br /&gt;
&lt;br /&gt;
Prelude is committed to providing an Hybrid IDS that offers the ability to unify currently available tools into one, powerful, and distributed application.&lt;br /&gt;
&lt;br /&gt;
http://www.prelude-ids.org/&lt;/div&gt;</summary>
		<author><name>KathyBennett</name></author>	</entry>

	</feed>