BCIT COMP 8045 Practicum Report by Wesley Kenzie, May 2012

COMP 8045 Major Project 1Bachelor of Technology Practicum ReportFebruary 2012 (Updated May 2012)Arthur (Wesley) Kenzie A00242330 [email protected]

______________________________________________________________________________Copyright © 2012. Arthur (Wesley) Kenzie. All Rights Reserved.

mailto:[email protected]


This report is the Author’s submission marking completion of the Practicum component to earning a Bachelor of Technology degree in Computer Systems from BCIT in both the Network Security Administration option and the Network Security Development option.

This updated version of the report incorporates feedback received from the Practicum Project Review Committee.

1. INTRODUCTION 1(a) Problem Background ....................................... page 2 1(b) Goals and Objectives ....................................... page 3 1(c) Planned Scope and Depth ....................................... page 5 1(d) Test Plan ....................................... page 6 1(e) Planned Methodology ....................................... page 8 1(f) Planned Technologies ....................................... page 9 1(g) Planned Milestones ....................................... page 9 1(h) Planned Deliverables ....................................... page 10

2. BODY 2(a) Project Background ................................................. page 11 2(b) Project Statement ................................................. page 11 2(c) Alternative Solutions ................................................. page 12

2(d) Choices and Rationale (i) Development Language/Platform .............................. page 12 (ii) OpenSSL .............................. page 13 (iii) Thandy .............................. page 13 (iv) Remote/Distributed Cache .............................. page 13 (v) Remote Logging .............................. page 14 (vi) Personal Certificate Store .............................. page 14

2(e) Development Details (i) Feasibility Assessment ........................................ page 14 >> Test/Demonstration << ........................................ page 15 >> Selected Source Code << ........................................ page 29 (ii) Use Case Diagrams/Analysis ........................................ page 47 (iii) Sequence Diagram ........................................ page 48 (iv) Class Diagram ........................................ page 49 (v) Object Diagram ........................................ page 50 (vi) Collaboration Diagram ........................................ page 51

2(f) Implementation Implications (i) Configuration ........................................................... page 52 (ii) Logging ........................................................... page 57 (iii) Middleware Observation ....................................... page 57 (iv) IPv6 ........................................................... page 57

BCIT School of Computing and Academic Studies COMP 8045 Major Project 1Date: February 2012 (Updated: May 2012)Author: Arthur (Wesley) Kenzie A00242330 [email protected] of Technology Practicum Report______________________________________________________________________________

______________________________________________________________________________Copyright © 2012. Arthur (Wesley) Kenzie. All Rights Reserved. Page 1 of 72



(v) Certificate Trust ........................................................... page 58

2(g) Applicable New Technology Research .............................. page 58

2(h) Milestones and Deliverables .............................. page 58

2(i) Future Enhancements (i) Shorter Term ........................................................... page 61 (ii) Longer Term ........................................................... page 61

3. CONCLUSIONS ........................................................... page 63

4. APPENDIX 4(a) Bibliography ........................................................... page 64 4(b) DVD Contents ........................................................... page 72

1. INTRODUCTION

This Practicum was focused on the design, development, and testing of an open source proxy application (called “Proxyup”) that can be inserted into a normally end-to-end encrypted TLS/SSL connection for a variety of possible benefits and protections to any client-side application. The server side of this connection communicates directly with the proxy, rather than directly with the client-side application, without any observed reduction in functionality and without any observed increase in risk to either the server or the client-side application, other than the risks discussed in 2(f) Implementation Implications.

The initial uncertainty as to whether development of this proxy application could be accomplished has been eliminated: the author has successfully developed a basic implementation as originally proposed, other than the changes discussed in 2(d) Choices and Rationale starting on page 12.

This software application provides proxy services for both HTTP and HTTPS protocols, because HTTPS is simply HTTP wrapped up inside the TLS/SSL protocol.

1(a) Problem Background

Transport Layer Security (“TLS”) and its predecessor, Secure Sockets Layer (“SSL”), are cryptographic protocols that ensure end-to-end “secure” network connections between a server process and a client-side application. Secure in this sense means that eavesdropping and tampering of the network connection contents are prevented - what can be referred to as providing confidentiality and nonrepudiation. TLS/SSL also provides authentication - typically unilateral authentication, meaning that the server identity is known to the client-side application, but not vice versa.





One of the major problems - likely THE major problem - with the usual implementations of TLS/SSL is that the certificate presented to client-side applications by the server cannot easily be verified with sufficient certainty at all times. This has resulted in widespread reliance on “trusted CA” lists, and widespread adoption of “trust-on-first-use” mechanisms. It is also problematic when the server certificate changes or is revoked. Certificate changes might be entirely legitimate, but they also might signal a potential man-in-the-middle (“MITM”) attack whereby some third-party adversary has positioned itself into a network connection posing as the server which the client-side application had previously decided was trusted. Most mechanisms in place today fail to adequately protect against MITM attacks. In fact a number of respected commentators have declared that TLS/SSL implementations, because of their limited perspective reliance on Public Key Cryptography and the Public Key Infrastructure (“PKI”) are broken because of this weakness[1]

[2][3][4][5][7][8][38][47][48][49][75].

An additional problem with TLS/SSL implementations is the fact that portions of each implementation are typically embedded in each client-side application, and thus require patches or upgrades from each client-side application developer when weaknesses or anomalies are found. For proprietary client-side apps, this problem is compounded, because the weaknesses and anomalies are opaque to independent analysis. If these app developers are not responsive to addressing weaknesses and anomalies, the user is left vulnerable to exploitation.

1(b) Goals and Objectives

The proxyup application created for this Practicum Project enables improved protection for client-side applications against TLS/SSL MITM attacks by allowing for the proxy app to take responsibility for some or all decisions with regards to server certificate authenticity. A key component of this enabling is the capturing and analysis of server certificate details that are pooled by the proxyup app user base. This aggregation of certificate details is conceptually similar to the EFF’s SSL Observatory project[47][77], but goes beyond by enabling dynamic use of this information by the proxy app, and is not limited to certificate details collected only from Mozilla Firefox users.

Proxyup also provides an open source infrastructure that could be useful as a standardized, improved implementation of TLS/SSL. In this regard, as discussed in 2(i) Future Enhancements, the proxyup app is intended to make use of certificate trust notaries as implemented by the Perspectives Project[49] and Convergence[50] as a means of improving on the limitations of the existing TLS/SSL certificate trust model. Additionally the proxyup app is intended to incorporate the certificate auditing functionality proposed by Google[75]. Each of these 3 enhancements have been proposed very recently, and consequently there was insufficient time to include them in this Practicum Project.

The list of benefits and protections provided or planned for client-side applications by this Project as a result of encapsulating the encryption and authentication logic into the proxy application that is typically embedded in the client-side application are as follows:

(1) the encryption and authentication design and implementation are made available for open source peer review, rather than being embedded and hidden in the (sometimes)





proprietary machine code of the client-side applications;

(2) the open source license to the proxyup software application allows, and hopefully encourages, other developers and users to contribute improvements and fixes to it;

(3) client-side applications can benefit from more timely patches created to address newly discovered vulnerabilities or weaknesses in any of the encryption or authentication protocols or implementations in the proxyup application, since it is assumed that many of these patches can be made independently of all the other code and functionality embedded inside these client-side applications;

(4) client-side applications can be upgraded to use more secure or more robust or more reliable TLS/SSL protocols or protocol implementations, independent of any upgrades made available by the client-side application developers;

(5) certain deficiencies and weaknesses in the client-side applications can be more easily addressed in some cases, thus extending the useful life and domain of these applications;

(6) “best practices” for encryption and authentication by client-side applications can be more easily standardized, with any number of the apps being made to use the same proxyup application instance rather than having them implement their own separate and likely different sets of “best practices”;

(7) trusted certificate authorities (“CA’s”) can be better managed, with the proxyup application taking some or all responsibility for this, rather than relying on trusted CA’s embedded in the proprietary machine code of the client-side applications, or parameterized in some obscure and insecure way by the applications or operating system;

(8) better management of trusted CA’s and trusted certificates by the proxy can be achieved, using one or more techniques for allowing user-centric access by client-side applications from any location, any device, any time;

(9) a local, shared and perhaps transparent instance of the proxy can be used to consolidate TLS/SSL connections from not only multiple client-side applications, but also multiple client environments/users in an organization;

(10) improved protection against TLS/SSL man-in-the-middle (“MITM”) attacks through more security-aware algorithms in the proxyup application, and better management of trusted CA’s, certificate revocations and certificate transitions;

(11) static content from TLS/SSL connections can be cached to enable faster access and reduced transmission times;

The proxyup application works by imitating a client-side application to the server, and by generating appropriate self-signed certificates as a form of pseudo-server to each client-side application. To each client-side app, the proxyup app appears to be the actual server being accessed. To each server, the proxyup app appears to be the actual client-side app that is behind it.





1(c) Planned Scope and Depth

The initial use case for the proxy was a Firefox browser client-side application running on a single Linux desktop. Firefox was configured to use the proxy for all its TLS/SSL connections. The knowledge gained from this use case was integrated into improvements and changes before moving forward.

Single-user Firefox was followed by two additional single-user desktop use cases in turn: the wget[33] and cURL[24] client-side applications.

Each of these single-user desktop application use cases were then planned to be followed by use cases involving two or more instances of various combinations of these applications on the same desktop, as well as use cases manufactured by way of various testing tools[26][27][28][29][34].

Multiple-instance single-user desktop use cases were then planned to be followed by multiple-user use cases, with two or more desktops using Firefox to connect through the proxy simultaneously, followed by two or more wget[33], two or more cURL[24] users/desktops, and finally various combinations of these.

Only unilateral authentication was included in the proxy, not bilateral where the server knows the identity of the client it is communicating with. This means that client-side applications will remain unauthenticated, or essentially anonymous to the server.

Only TLS/SSL is supported by the initial release of the proxy. Plans for additional protocol support are described in 2(i) Future Enhancements.

Support for either GnuTLS[19] or yaSSL[22] was planned, rather than OpenSSL[20], however this was revisited as per reasons described in 2(d) Choices and Rationale.

Both IPv4 and IPv6[85] connections are supported by the proxy, either simultaneously, or exclusively one or the other. Multi-homing is supported by the proxy, with any number of local interfaces, any number of local IP addresses, and any number of public IP addresses on the local client machine. Support for multi-threading was planned but found to be unnecessary for reasons described in 2(d) Choices and Rationale.

The Cipher Suites initially supported are RC4-SHA, AES128-SHA, and AES256-SHA. SSL versions 1 and 2 are not supported, TLS versions 1.0 and 1.1 are not supported, and MD5 hash functions are not supported, all due to security vulnerability concerns.

The proxy was planned to update/patch itself automatically on a user-defined update schedule, to ensure it is appropriately current with its protections and benefits. This plan was revisited as per reasons described in 2(d) Choices and Rationale.

The store of trusted certificates and certificate authorities was planned to be kept on the equivalent of a TrueCrypt[9] or Tahoe™ [10] secure file system, located on one or more Tor[31]





hidden services[11] in order to provide support for mobility (i.e. persistent use by end-user identity from any device, any location), privacy, and anonymity. Support for distributed hash tables[15] via Apache Cassandra[16][86] was planned in order to achieve the additional advantages of fault-tolerance, decentralization, elasticity, and tuneable consistency for the data store. These plans were revisited as per reasons described in 2(d) Choices and Rationale.

Support for a local caching function as part of the proxy similar to Polipo[17] or Tinyproxy[18] was planned to be included, with the goal being to reduce transmission times for the secure network connections. Support for remote caching was also to be included at the same implementation/release timeframe as Cassandra, since was planned that the remote caching be implemented as a distributed hash table. These plans were revisited as per reasons described in 2(d) Choices and Rationale.

1(d) Test Plan

The following tests were planned to be performed on the proxy during development:

(1) Allow client-side applications to make secure connection to server through the proxy on first use? (first time client-side application connects to this server)

(2) Allow client-side applications to operate “normally” with server, in same manner as without proxy being used? (other than when server certificate properties change, or when server certificate is discovered to be malicious, stolen, revoked, or otherwise invalid)

(3) Disallow client-side applications to make secure connection to server through the proxy on subsequent use, with any change to server certificate properties?

(4) Record details of server certificate properties on first use to data store?

(5) Show changes to end-user of any server certificate properties on subsequent use?

(6) Record changes of any server certificate properties to specified log file?

(7) Record use of server certificate to data store? (not simply certificate properties)

(8) Recognize any changes to server certificate properties during existing connection with client-side applications?

(9) Recognize expiry date of server certificate (both prior to establishing secure connection and during existing secure connection)?

(10) Recognize revocation of server certificate? (prior to establishing secure connection)

(11) Recognize replacement of server certificate? (both prior to establishing secure connection and during existing secure connection)

(12) Show differences between server certificate presented to client-side applications by server and any server certificates presented to other end-users and other client-side applications by same server?

(13) Disallow client-side applications to make secure connection to server through the proxy at any time differences are discovered between server certificate presented, and other server certificates presented to other end-users and other client-side applications?





(14) Each supported Cipher Suite works as expected?

(15) Each supported TLS and SSL and DTLS[25][52] versions work as expected?

(16) IPv4 connections work as expected?

(17) IPv6[85] connections work as expected?

(18) Simultaneous IPv4 and IPv6[85] connections work as expected?

(19) Simultaneous connections to same server on two separate local machine interfaces work as expected?

(20) Simultaneous connections to different servers on two separate local machine interfaces work as expected, both with same public IP addresses and with different public IP addresses?

(21) Two or more client-side applications connect to same server through proxy?

(22) Two or more client machines connect simultaneously through shared proxy to same server?

(23) Caching of decrypted specified static file types (.ico, .png, .jpg, .pdf, and .gif) successful?

(24) Use of cached specified static file types successful?

(25) Can signal proxy to exit after closing existing connections and posting to log file?

(26) Can signal proxy to immediately abort?

(27) Can signal proxy to re-read configuration file and continue with new settings?

(28) Can signal proxy to pause all secure connections until further notice?

(29) Can signal proxy to continue all secure connections after being previously paused?

(30) Can post to specified log file as configured?

(31) Do all unit tests work?

(32) Does the proxy leak any information about its presence to external probing by penetration testing or port probing or packet sniffing toolsets?

(33) Does the proxy leak any information about its presence to other devices on the same internal subnet?

(34) Does the proxy leak any information about its presence to other non-root processes on the same device?

(35) Does the proxy silently drop any attempted connections or probes originating externally (i.e. other than by a client-side application) that are not part of an existing secure TCP connection or session?

(36) Does the proxy silently drop any attempted connections or probes originating externally that are not part of an existing secure UDP session?





1(e) Planned Methodology

The proxy was designed in terms of architecture and core functionality to meet the requirements and use cases listed above. It was initially uncertain whether the development language would be C++, Java, or some other object-oriented language. The language eventually settled on was JavaScript, running on the node.js platform[60][61][62]. A discussion of this issue is included in 2(d) Choices and Rationale.

An Evolutionary Delivery lifecycle was planned, providing multiple release deliveries based around the following delivery plan:

(1) Support for a single-user Firefox secure connection through the proxy over IPv4 using one of the supported TLS or SSL versions, a single Cipher Suite, TCP, HTTPS, and a valid server certificate.

(2) Addition of support for local logging.

(3) Addition of support for a local data store.

(4) Addition of support for invalid server certificates.

(5) Addition of support for additional Cipher Suites.

(6) Addition of support for additional TLS and SSL versions.

(7) Addition of support for IPv6[85] connections.

(8) Addition of support for secure UDP connections using DTLS[25][52].

(9) Addition of support for expiring server certificates.

(10) Addition of support for revoked server certificates.

(11) Addition of support for multiple simultaneous client-side applications.

(12) Addition of support for multiple users.

(13) Addition of support for local caching of static objects.

(14) Addition of support for remote data store.

(15) Addition of support for distributed data stores. (optional)

(16) Addition of support for remote or distributed caching. (optional)

(17) Addition of support for remote logging. (optional)

With this Practicum project being open source, a public repository at launchpad.net/proxyup [63][64] was setup and maintained for the documentation and source code. This repository also facilitates, and hopefully encourages, peer review as well as contributions from other developers.





1(f) Planned Technologies

It was planned that development work would be done in either C++ using the Qt Creator[44] IDE, or in Java using either the Eclipse[45] or NetBeans[46] IDE. The possibility was considered that initial work would be done in both languages until or unless a clear advantage emerged for one over the other. A discussion and analysis of the technology decisions that were made is included in 2(d) Choices and Rationale.

The development operating system (“OS”) and target OS was Canonical’s 64-bit Ubuntu[96], one of the major Linux distributions.

Version control was done in Bazaar[42], since it is closely integrated with the launchpad.net repository web site that was used. Subversion[40], Git[41], and Google Code[43] were also considered.

Issue tracking and bug tracking is incorporated into the launchpad.net repository service, and so a separate product such as Trac[30] was not required.

Testing was planned to be done with Firefox[32], wget[33], cURL[24], hping3[27], Wireshark[34], Seagull[26], nMap[28], and Ncat[29].

Either GnuTLS[19] or yaSSL[22] were initially planned to provide the TLS, SSL and DTLS libraries, but as discussed in 2(d) Choices and Rationale, OpenSSL[20] was selected instead.

The Tor[31] client software, Tor hidden services[11], and OnionCat[14] were to be used to host and access the remote data store. The data store was planned to make use of either a TrueCrypt[9] or Tahoe™ [10] secure file system, and was to be attempted as a clustered implementation of Apache Cassandra[16][86] nodes. As stated elsewhere, these plans were revisited as per reasons described in 2(d) Choices and Rationale.

1(g) Planned Milestones

Each planned milestone from 1 to 14 (shown below) was based on the releases specified in the 1(e) Planned Methodology section above.

Milestone 0: Delivery of detailed design specification.Milestone 1: Delivery of version 0.1 as per Evolutionary Delivery Lifecycle step (1)Milestone 2: Delivery of version 0.1.1 as per Evolutionary Delivery Lifecycle step (2)Milestone 3: Delivery of version 0.1.2 as per Evolutionary Delivery Lifecycle step (3)Milestone 4: Delivery of version 0.2 as per Evolutionary Delivery Lifecycle step (4)Milestone 5: Delivery of version 0.2.1 as per Evolutionary Delivery Lifecycle step (5)Milestone 6: Delivery of version 0.2.2 as per Evolutionary Delivery Lifecycle step (6)Milestone 7: Delivery of version 0.3 as per Evolutionary Delivery Lifecycle step (7)Milestone 8: Delivery of version 0.4 as per Evolutionary Delivery Lifecycle step (8)





Milestone 9: Delivery of version 0.5 as per Evolutionary Delivery Lifecycle step (9)Milestone 10: Delivery of version 0.6 as per Evolutionary Delivery Lifecycle step (10)Milestone 11: Delivery of version 0.7 as per Evolutionary Delivery Lifecycle step (11)Milestone 12: Delivery of version 0.8 as per Evolutionary Delivery Lifecycle step (12)Milestone 13: Delivery of version 0.9 as per Evolutionary Delivery Lifecycle step (13)Milestone 14: Delivery of version 1.0 as per Evolutionary Delivery Lifecycle step (14)

Milestone 14 was planned for completion by December 31, 2011. Milestone 0 was targeted for March 31, 2011. Target dates for Milestones 1 through 13 were considered flexible, based on challenges encountered and adjustments required. Additional Milestones beyond 14 were considered to be optional, if time permitted.

1(h) Planned Deliverables

A written detailed design specification was to be the first deliverable, as per Milestone 0 described above. All subsequent deliverables were planned to include a working proxy, source code, unit tests, updated specifications highlighting changes incorporated from feedback to previous releases, technical documentation for programmers, implementation documentation for system administrators, and user-centric documentation for end-users.





2. BODY

Details about the proxyup software application developed for this Practicum are discussed below.

2(a) Project Background

In November 2010 the author submitted his Practicum Proposal for consideration by the Practicum Review Committee. No Industry Sponsor was identified for inclusion on the Committee because the author was embarking on a new career path in the Computer Network Security industry, and was unable to find an organization prepared to make this commitment. The Proposal was approved on November 24, 2010 with a target completion date of November 24, 2011. In October 2011 the target completion date was extended to February 24, 2012, at the request of the author due to extraneous circumstances.

The design and development of the proxy software application was chosen by the author for this Practicum for a number of reasons. Primarily this proxy application was intended to assist the very large audience of Internet users who are vulnerable to current weaknesses in the TLS/SSL certificate trust design [1][2][3][4][5][7][8][38][47][48][49][75]. The author believed that if an open source framework could be built as a proxy application which encapsulated the important TLS/SSL protocols, then there could be a significant opportunity for advancing its popularity and advocating for its ubiquitous use. The attack against the Dutch Certificate Authority DigiNotar in June 2011[53]

[54][55] served to reinforce the relevance of this goal.

Secondarily there were the challenges of investigating the feasibility of tapping into the end-to-end encryption of TLS/SSL connections; of building a highly scalable, highly portable proxy service that could service everything from an individual client-side browser app to an entire organization’s HTTPS Internet traffic; of discovering how to parse HTTP request and response packets; and of learning how to design and create an asynchronous, event-driven software application that did not rely on multiple processes or on multi-threading.

2(b) Project Statement

This Practicum Project is focused on the design and development of an open source proxy software application that will operate transparently between a client-side software application such as an Internet “browser” and an HTTP web server. The proxy application will support both HTTP and HTTPS connections from the client-side app to the web server, and will attempt to enable decrypted access to the normally end-to-end encrypted HTTPS connections. A primary goal of this Project is to encapsulate a significant portion of TLS/SSL features and functions within the proxy app in order to provide a range of benefits for the client-side applications configured to use it. A complete list of goals is listed above in section 1(b) Goals and Objectives.





2(c) Alternative Solutions

There were no alternative solutions considered for this Practicum Project, other than the choice of development language, which is discussed next in section 2(d) Choices and Rationale. A search by the author for open source proxies that were able to decrypt TLS/SSL communications and meet the other goals of this Project turned up no existing solutions.

2(d) Choices and Rationale

(i) Development Language/Platform

The initial plan for the Practicum was for the proxy software application to be written in either Java or C++, or perhaps both simultaneously. Either of these would have met the project goal of portability. The author chose instead to begin development work in C, however, having become relatively comfortable with this language during the COMP 7005, 8005, and 8505 courses taken during the September 2010 to June 2011 period. C also promised to be easily portable, and scalable through use of the cross-platform libevent[58][59] event notification library, which was selected as the mechanism for event-driven processing because of its functionality, relative stability, and fairly extensive use in other open source projects[59].

The first commit of the C-based proxy source code was pushed to its public repository at https://launchpad.net/gybproxy on March 31, 2011[56] as the “GYB Proxy Project”, and over the course of the next 9 months until December 22, 2011[57] a total of 162 additional revisions were committed. Unfortunately progress was generally slow, and the author’s unfamiliarity with libevent[58][59] made the prospects for timely completion of this Project relatively dim. As a result of a chance encounter with the node.js platform[60][61][62] while the author was searching for an open source HTTP parsing library, the decision was made to abandon the original project code and switch development to JavaScript, on top of the node.js platform.

Node.js is a relatively new platform, built on top of the open source Google Chrome V8[65] JavaScript engine, the open source libev[90][91] event notification library, and the open source c-ares[92][93] asynchronous DNS library. It “uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices”[66] according to the web site http://HowToNode.org. Node.js does not use threading, and so does not employ any semaphore locking, thus eliminating the risks inherent in managing locks, greatly simplifying program design and debugging, and reducing memory requirements. Neither does it fork separate processes when run as a server to handle each client connection, thus significantly reducing stack memory requirements.

The impressive user/customer base of node.js now includes Microsoft (for use with Windows Azure[67][68][69] as of November 2011), eBay (as the core technology in ql.io[70] as of November 2011), LinkedIn (as the core technology in its mobile app[71] as of August 2011), Yahoo (in Yahoo! Mail[72] as of July 2010), and Facebook (in Facebook Chat for traffic analysis and load testing[73][74] as of May 2011), among others.



https://launchpad.net/gybproxy




http://HowToNode.org

http://HowToNode.org



The author discovered that node.js provided easy-to-use asynchronous, non-blocking JavaScript wrappers around all of the TCP packet handling and I/O functions needed by the proxy app, allowing for much faster development and testing, and producing significantly more manageable code. The fact that both clients and servers could be developed using the same JavaScript-on-node.js code base was also an important consideration, as was extensive, native support for the HTTP protocol.

The first commit of this Practicum Project’s JavaScript-based source code was pushed to its public repository at https://launchpad.net/proxyup on January 12, 2012[63] as the renamed “Proxyup Project”, and over the course of the next month until February 12, 2012[64] a total of 95 additional revisions were committed. The proxy is currently able to handle port 80 HTTP traffic, and port 443 HTTPS traffic, while decrypting in real-time all the TLS/SSL encrypted packets without the client-side application or the server being aware of its presence.

(ii) OpenSSL

With respect to using or not using OpenSSL[20], the author originally proposed supporting only GnuTLS[19] or yaSSL[22] due to the apparent incompatibility of the OpenSSL license with the GPL[21]. However, the node.js platform[60][61][62] currently only supports OpenSSL for its cryptographic components, but is licensed for use under the MIT License[83][84] which appears to address the author’s initial concerns. OpenSSL is thus supported in this Project, and neither GnuTLS nor yaSSL are supported. GnuTLS does support the DTLS[19][25][52] protocol, however, and so will be considered again when DTLS functionality is being implemented.

(iii) Thandy

With respect to meeting the design requirements in the Thandy[36][37][39] secure, auto/self updating specification, this has not been done due to the choice of the node.js platform[60][61][62] for development. The node.js platform already has a package manager, npm, which includes self-updating, and the Thandy spec would need to be added to it. Adding Thandy functionality to npm was considered to be out of scope for this Project.

(iv) Remote/Distributed Cache

No support will be added for remote or distributed caching of static files. The original plan was to offer primary, local caching of static files as a means of reducing the amount of data to be downloaded from servers to the client-side apps, and therefore speeding up the user’s HTTP and HTTPS browsing experience. If a static file was not found in the local cache, it was planned that a secondary remote or distributed cache would be used, with the advantage being that users who had not encountered a particular static file before, would gain the caching benefit of other users having accessed this file before them, and thus put it into a shared cache. The author decided these possible benefits were not significant relative to all the other functionality being put into the proxyup app.



https://launchpad.net/proxyup




(v) Remote Logging

No direct support will be added for remote logging, as originally planned. Instead, support will be added for logging to syslog, and then system support for remote logging of syslog[87] will be relied upon.

(vi) Personal Certificate Store

A persistent store of trusted certificates and certificate authorities was planned on the equivalent of a TrueCrypt[9] or Tahoe[10] secure file system, located on one or more Tor[31] network hidden services[11] in order to provide support for user-centric mobility (i.e. persistent use by end-user identity from any device, any location), privacy, and anonymity. Support was also discussed about using Apache Cassandra[16][86] in order to achieve the additional advantages of fault-tolerance, decentralization, elasticity, and tuneable consistency for this data store. While still considered a worthy design goal, the author has decided that the complexity and effort required to support personal certificate stores in this manner is out of scope for this Project.

2(e) Development Details

Details about the analysis, design and implementation of the proxyup software application developed for this Practicum are discussed below.

(i) Feasibility Assessment

The Practicum Proposal for this Project submitted in November 2010 clearly identified the technical feasibility of this Project as uncertain.

“It should be stated that there is some uncertainty as to whether development of such a proxy can actually be accomplished. No existing open source proxy with similar functionality has been identified, nor does it appear that any major desktop “internet security” software companies have implemented such a program. However, initial research into the TLS/SSL and DTLS protocols and a review of the open source GnuTLS[19] and yaSSL[22] libraries has provided some confidence that the goals of this Practicum can be achieved.”

Work completed to date on this Project has shown that HTTPS connections between a client-side application and a remote server on the public Internet can be successfully proxied, and can be dynamically decrypted. This Project has also proven that server certificates can be captured and used by the proxy as the basis for improving protection for the user. There is every reason to believe that further work on the proxy software application will be as refinements to the Project goals, rather than as further attempts at assessing its technical feasibility.

With respect to time and cost constraints, the scope and depth of the Practicum Proposal was overly optimistic. The previous section 2(d) Choices and Rationale, and a following section 2(i) Future Enhancements, describe the changes and compromises made to the original specification.





In hindsight, it appears it was not feasible to implement DTLS or Personal Certificate Stores in scope due to the amount of effort required. It likely would have been feasible to implement local caching of static files, as well as persistent storage and additional processing of server certificates had node.js been used from the start. Using C as the development language was an exercise for the author in progressing slowly, but it did provide good experience in understanding more about what can be accomplished in C in a given timeframe.

>> Test/Demonstration <<

Now to demonstrate. The proxyup app was started on a Ubuntu 10 64-bit VM from the ~/node/proxyup directory using the command “node .” as shown below. Wireshark was already started, running in the background, logging all packets in promiscuous mode to a test1.pcap file.





The complete contents of the /var/log/proxyup1.log file are shown below. Note the “(5347)” after the UTC date/time on each log entry: this is the process ID of the proxy app.

Also note the network interface eth0 shown highlighted on the 12th log entry: the private IPv4 address is 192.168.0.186 and IPv6 address is fe80::21c:42ff:fefc:3f9.

Also note that at 2012-02-18T22:36:51.276Z the HTTP proxy starts listening for incoming connections on 127.0.0.1:8080 and the HTTPS proxy starts listening on 127.0.0.1:8443.

The first connection made to the HTTPS proxy is shown highlighted as 2012-02-18T22:37:25.712Z (5347) [debug] client 127.0.0.1:39934 connected to https proxy port 8443. This corresponds to Frame 243 shown further below in the test1*.pcap file captured by Wireshark. The initial TCP 3-way handshake between the client and the proxy are actually not shown in the log file, but they are shown in the pcap file, as Frames 240, 241 and 242. Frame 243 is where the CONNECT request arrives from the client, which the proxy

2012-02-18T22:36:51.089Z (5347) [debug] logging to /var/log/proxyup1.log2012-02-18T22:36:51.093Z (5347) [debug] process 'node' now running as 'proxyup'2012-02-18T22:36:51.093Z (5347) [info] proxyup 0.2 build 29.2012.02.12 on /usr/local/bin/node v0.6.102012-02-18T22:36:51.093Z (5347) [debug] started with no parameters2012-02-18T22:36:51.093Z (5347) [debug] user root gid 0/uid 0 in /home/juliec/node/proxyup2012-02-18T22:36:51.093Z (5347) [debug] host securikai-vm3.local on linux x64 2.6.32-38-generic2012-02-18T22:36:51.093Z (5347) [debug] node built with v8 version 3.6.6.202012-02-18T22:36:51.093Z (5347) [debug] node built with ares version 1.7.5-DEV2012-02-18T22:36:51.094Z (5347) [debug] node built with uv version 0.62012-02-18T22:36:51.094Z (5347) [debug] node built with openssl version 0.9.8k2012-02-18T22:36:51.094Z (5347) [debug] network interface lo: [{"address":"127.0.0.1","family":"IPv4","internal":true},{"address":"::1","family":"IPv6","internal":true}]2012-02-18T22:36:51.094Z (5347) [debug] network interface eth0: [{"address":"192.168.0.186","family":"IPv4","internal":false},{"address":"fe80::21c:42ff:fefc:3f9","family":"IPv6","internal":false}]2012-02-18T22:36:51.094Z (5347) [debug] pid saved to /var/run/proxyup.pid2012-02-18T22:36:51.163Z (5347) [debug] available middleware: tlsware2012-02-18T22:36:51.163Z (5347) [debug] available middleware: logware2012-02-18T22:36:51.164Z (5347) [debug] middleware search path: /home/juliec/node/proxyup,./manhandlers,../manhandlers,/home/juliec/node/proxyup/lib/manhandlers2012-02-18T22:36:51.260Z (5347) [info] starting tls middleware service on https://127.0.0.1:81152012-02-18T22:36:51.276Z (5347) [info] starting http proxy on 127.0.0.1:80802012-02-18T22:36:51.276Z (5347) [info] starting https proxy on 127.0.0.1:84432012-02-18T22:36:59.541Z (5347) [debug] [proxyPrep] request from 127.0.0.1:55704 for http://fxfeeds.mozilla.com/en-US/firefox/headlines.xml2012-02-18T22:36:59.543Z (5347) [debug] http request headers: {"host":"fxfeeds.mozilla.com","user-agent":"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","accept-language":"en-us,en;q=0.5","accept-



https://127.0.0.1:8115

https://127.0.0.1:8115

https://127.0.0.1:8115

https://127.0.0.1:8115

http://fxfeeds.mozilla.com/en-US/firefox/headlines.xml






encoding":"gzip, deflate","proxy-connection":"keep-alive","x-moz":"livebookmarks","if-modified-since":"Thu, 16 Feb 2012 08:41:38 GMT","cache-control":"max-age=0"}2012-02-18T22:36:59.658Z (5347) [debug] [bodyLogger] unzipping response statusCode 302 data with headers {"content-encoding":"gzip","cache-control":"max-age=604800","content-type":"text/html; charset=iso-8859-1","date":"Sat, 18 Feb 2012 22:37:01 GMT","expires":"Sat, 25 Feb 2012 22:37:01 GMT","last-modified":"Thu, 16 Feb 2012 08:41:38 GMT","location":"http://fxfeeds.mozilla.com/firefox/headlines.xml","server":"ECS (sea/55EB)","vary":"Accept-Encoding","x-backend-server":"pm-web04","x-cache":"302-HIT","x-cache-info":"cached, cached","content-length":"200"} for 127.0.0.1:557042012-02-18T22:36:59.661Z (5347) [debug] [proxyPrep] request from 127.0.0.1:55704 for http://fxfeeds.mozilla.com/firefox/headlines.xml2012-02-18T22:36:59.661Z (5347) [debug] http request headers: {"host":"fxfeeds.mozilla.com","user-agent":"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","accept-language":"en-us,en;q=0.5","accept-encoding":"gzip, deflate","proxy-connection":"keep-alive","if-modified-since":"Tue, 14 Feb 2012 18:17:35 GMT","cache-control":"max-age=0"}2012-02-18T22:36:59.777Z (5347) [debug] [bodyLogger] unzipping response statusCode 302 data with headers {"content-encoding":"gzip","cache-control":"max-age=604800","content-type":"text/html; charset=iso-8859-1","date":"Sat, 18 Feb 2012 22:37:01 GMT","expires":"Sat, 25 Feb 2012 22:37:01 GMT","last-modified":"Tue, 14 Feb 2012 18:17:35 GMT","location":"http://newsrss.bbc.co.uk/rss/newsonline_world_edition/front_page/rss.xml","server":"ECS (sea/55F0)","vary":"Accept-Encoding","x-backend-server":"pm-web03","x-cache":"302-HIT","x-cache-info":"cached, cached","content-length":"220"} for 127.0.0.1:557042012-02-18T22:36:59.816Z (5347) [debug] [proxyPrep] request from 127.0.0.1:55704 for http://newsrss.bbc.co.uk/rss/newsonline_world_edition/front_page/rss.xml2012-02-18T22:36:59.817Z (5347) [debug] http request headers: {"host":"newsrss.bbc.co.uk","user-agent":"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","accept-language":"en-us,en;q=0.5","accept-encoding":"gzip, deflate","proxy-connection":"keep-alive","cookie":"BBC-UID=24afb347c34ff9f41a9af21851b51c39b50201a900c05121029203c3e4a4a5c50Mozilla%2f5%2e0%20%28X11%3b%20Ubuntu%3b%20Linux%20x86%5f64%3b%20rv%3a10%2e0%29%20Gecko%2f20100101%20Firefox%2f10%2e0; s1=4F373F9B5C000363; s_vnum=1331612829646%26vn%3D2; s_nr=1329020829647; s_ev49=%5B%5B'Direct%2520Load'%2C'1329020829649'%5D%5D; rsi_segs=J08781_10114|J08781_10115|J08781_10120|J08781_10154|J08781_10155|J08781_10212|J08781_10263|J08781_10282|J08781_10293|J08781_10294|J08781_10312|J08781_10335|J08781_10405|J08781_10406|J08781_10432|J08781_10433|J08781_10434|J08781_10438|J08781_10440|J08781_10441|J08781_10450|J08781_10451|J08781_10463|J08781_10464|J08781_10466|J08781_10467|J08781_10475|J08781_10492|J08781_10499|J08781_10502|J08781_10503|J08781_10508|J08781_10541; _em_vt=56b4767a874e997afaae86d3f46d4f373f9e39dd12-589589314f37498c; _em_vt=31b2dc34d200138363be86d3f46d4f373f9e39dd12-589589314f373f9e","cache-control":"max-age=0"}2012-02-18T22:36:59.931Z (5347) [debug] [bodyLogger] response statusCode 301 data (256 bytes) with headers {"server":"Apache","location":"http://feeds.bbci.co.uk/news/rss.xml?edition=int","content-length":"256","content-type":"text/html; charset=iso-8859-1","cache-control":"max-age=87968851","expires":"Wed, 03 Dec 2014 02:24:32 GMT","date":"Sat, 18 Feb 2012 22:37:01 GMT","connection":"close","vary":"Accept-Encoding"} for 127.0.0.1:557042012-02-18T22:36:59.936Z (5347) [debug] [proxyPrep] request from 127.0.0.1:55708 for http://feeds.bbci.co.uk/news/rss.xml?edition=int2012-02-18T22:36:59.936Z (5347) [debug] http request headers: {"host":"feeds.bbci.co.uk","user-agent":"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","accept-language":"en-us,en;q=0.5","accept-encoding":"gzip,



http://fxfeeds.mozilla.com/firefox/headlines.xml






http://newsrss.bbc.co.uk/rss/newsonline_world_edition/front_page/rss.xml








http://feeds.bbci.co.uk/news/rss.xml?edition=int










deflate","proxy-connection":"keep-alive","if-modified-since":"Sat, 18 Feb 2012 18:45:55 GMT","cache-control":"max-age=0"}2012-02-18T22:37:00.043Z (5347) [debug] [bodyLogger] unzipping response statusCode 200 data with headers {"server":"Apache","last-modified":"Sat, 18 Feb 2012 22:36:29 GMT","content-type":"text/xml","content-encoding":"gzip","content-length":"8308","cache-control":"max-age=93","expires":"Sat, 18 Feb 2012 22:38:34 GMT","date":"Sat, 18 Feb 2012 22:37:01 GMT","connection":"close","vary":"Accept-Encoding"} for 127.0.0.1:557082012-02-18T22:37:02.667Z (5347) [debug] tls middleware connection from client session 116898687514765388752012-02-18T22:37:25.712Z (5347) [debug] client 127.0.0.1:39934 connected to https proxy port 84432012-02-18T22:37:25.713Z (5347) [debug] https proxy getCerts(www.ippages.com) looking for certs in ./keys/certs2012-02-18T22:37:25.714Z (5347) [debug] https proxy getCerts(www.ippages.com) key: 1675 bytes2012-02-18T22:37:25.714Z (5347) [debug] https proxy getCerts(www.ippages.com) cert: 1107 bytes2012-02-18T22:37:25.715Z (5347) [info] client 127.0.0.1:39934 (ua curl/7.19.7) connecting through https proxy to server www.ippages.com2012-02-18T22:37:25.718Z (5347) [debug] client 127.0.0.1:39934 server null data event (115 bytes): not secure2012-02-18T22:37:25.723Z (5347) [debug] client 127.0.0.1:39934 server www.ippages.com data event (326 bytes): secure {}2012-02-18T22:37:25.723Z (5347) [debug] [proxyPrep] request from 127.0.0.1:39934 for https://www.ippages.com/simple/2012-02-18T22:37:25.724Z (5347) [debug] [proxyPrep] request from 127.0.0.1:39934 for https://www.ippages.com/simple/2012-02-18T22:37:25.724Z (5347) [debug] [proxyPrep] request from 127.0.0.1:39934 for https://www.ippages.com/simple/2012-02-18T22:37:25.725Z (5347) [debug] https request headers: {"user-agent":"curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15","host":"www.ippages.com","accept":"*/*"}2012-02-18T22:37:25.726Z (5347) [debug] client 127.0.0.1:39934 server www.ippages.com data event (197 bytes): secure {}2012-02-18T22:37:27.044Z (5347) [info] server www.ippages.com (212.117.170.54:443) certificate valid starting Aug 25 22:23:53 2011 GMT2012-02-18T22:37:27.045Z (5347) [info] server www.ippages.com (212.117.170.54:443) certificate valid until Aug 30 22:43:00 2012 GMT2012-02-18T22:37:27.045Z (5347) [info] server www.ippages.com (212.117.170.54:443) certificate fingerprint 22:8D:F5:1A:13:96:3D:11:76:D4:3A:CC:BC:A1:FF:97:E3:E9:D3:172012-02-18T22:37:27.045Z (5347) [info] server www.ippages.com (212.117.170.54:443) certificate subject {"O":"www.ippages.com","OU":"Domain Control Validated","CN":"www.ippages.com"}2012-02-18T22:37:27.045Z (5347) [info] server www.ippages.com (212.117.170.54:443) certificate issuer {"C":"US","ST":"Arizona","L":"Scottsdale","O":"GoDaddy.com, Inc.","OU":"http://certificates.godaddy.com/repository","CN":"Go Daddy Secure Certification Authority","serialNumber":"07969287"}2012-02-18T22:37:27.045Z (5347) [debug] server TLS/SSL cert: {"subject":{"O":"www.ippages.com","OU":"Domain Control Validated","CN":"www.ippages.com"},"issuer":{"C":"US","ST":"Arizona","L":"Scottsdale","O":"GoDaddy.com, Inc.","OU":"http://certificates.godaddy.com/repository","CN":"Go Daddy Secure Certification Authority","serialNumber":"07969287"},"subjectaltname":"DNS:www.ippages.com, DNS:ippages.com","modulus":"AFB0B2667DB972B2AAB407C2E721AD1ACC0FB31966407068E40C024A223229C5E4909E88AE4403065427233046D8F81E671ECEC91BEE730CE130E079F67767276DAFEAC261A5CB1A32138A67B874C2F1C6EAC8950C6D77F2295AEE370826D4BF8AA3BE24F12AB6140378175D5C14AEAAF9F537B4DACDA29779E15C8E



http://www.ippages.com










https://www.ippages.com/simple/
























http://certificates.godaddy.com/repository














D20F388A9B5CFB074E06DEF8C422AEBD485C16CC92D810428A303F65F8D79DDE54B76A194F4A52E304CE64C0E9073C94859D22DEFED7480B5E25EBC33DE83A730E67E8238D7F935542BF63E2CA05B6E0A9A421582A655EC04E82A27992F51E6E97F24176295BA64B72475D1DC5A3DDE995072677E243DAAB6F85400B6796C13BF6BAD745","exponent":"10001","valid_from":"Aug 25 22:23:53 2011 GMT","valid_to":"Aug 30 22:43:00 2012 GMT","fingerprint":"22:8D:F5:1A:13:96:3D:11:76:D4:3A:CC:BC:A1:FF:97:E3:E9:D3:17","ext_key_usage":["1.3.6.1.5.5.7.3.1","1.3.6.1.5.5.7.3.2"]}2012-02-18T22:37:27.046Z (5347) [debug] [bodyLogger] response statusCode 200 data (13 bytes) with headers {"date":"Sat, 18 Feb 2012 22:37:28 GMT","server":"Apache/2.2.14 (Ubuntu)","x-powered-by":"PHP/5.3.2-1ubuntu4.14","pragma":"no-cache","cache-control":"no-cache, must-revalidate","vary":"Accept-Encoding","content-length":"13","keep-alive":"timeout=15, max=100","connection":"Keep-Alive","content-type":"text/html"} for 127.0.0.1:399342012-02-18T22:37:27.085Z (5347) [debug] client 127.0.0.1:39934 server www.ippages.com data event (37 bytes): secure {"receivedShutdown":true}2012-02-18T22:38:24.995Z (5347) [info] SIGINT signal received2012-02-18T22:38:24.996Z (5347) [info] program exit: code 0

Most of the log file entries shown above preceding the client-side app connecting to the HTTPS proxy at port 8443 at 2012-02-18T22:37:25.712Z were generated by the Firefox browser doing background updates for itself. They record communications through the proxy HTTP port 8080, and are not relevant for our demonstration purposes here.

The client-side app which initiated the port 8443 connection is shown below. curl was launched to access the url https://www.ippages.com/simple/ and the response from this web server is shown at the start of the 2nd line as 23.16.201.197 which is the public IP address of this device.

What the proxyup1.log entry highlighted above shows is that this decrypted server response “23.16.201.197” is received by the client-side app (curl) at port 39934 at 2012-02-18T22:37:27.046Z.

The Wireshark test1*.pcap file shown later has this server response arriving at the proxy in Frame 276 from the server, and forwarded by the proxy in Frame 277 to the client-side app. Nowhere in









the Wireshark test1*.pcap file, however, is this server response shown decrypted - only the proxy in this Practicum is able to do that.

Shown below is a portion of the Wireshark test1*.pcap file, filtered to show only TCP packets and to ignore any packets involving port 8115, which will be discussed later.

Note the first SYN packet in Frame 240 from the client-side app (curl) to port 8443 of the proxy. Note also that Frame 243 is the first TCP packet to send data, as indicated by the “[PSH, ACK]” flags.





The CONNECT request from the client-side app (curl) is what Frame 243 shows as sent to the proxy: CONNECT www.ippages.com:443 HTTP/1.1 Host: www.ippages.com:443 User-Agent: curl/7.19.7 (x86 64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.4 libidn/1.1.5 Proxy-Connection: Keep-Alive.

Frames 244 through 253 show the various packets back and forth between the client-side app (curl) and the proxy to establish a secure HTTPS connection between them.



http://www.ippages.com:443






Frame 259 shows the first SYN packet sent from the proxy out to the server’s port 443 to initiate a 3-way handshake on the “outbound” side of the proxy.

Frames 262 through 273 show the various packets back and forth between the proxy app and the server to establish a secure HTTPS connection between them. Once this is done, there are 2 separate secure HTTPS connections in place: client-proxy and proxy-server.

Frame 274 is an encrypted packet relayed (originally from the client-side app) from the proxy to server.

Frame 276 is an encrypted packet response sent from the server to the proxy.

Frame 277 is a relayed (originally arriving in Frame 276 from the server) and encrypted packet from the proxy to the client-side app. After that it is simply a matter of shutting down sockets.





Proof of the decryption and capture of server certificate data is shown next. Running at the same time as the proxy is a browser-based console the author has called “Proxyup TLS Middleware”. This console displays data the proxy is saving to a ring buffer in memory about each HTTP and HTTPS connection the proxy handles. The first level of data displayed by the console is shown below, with one summary entry for each request initiated by a client-side app.

There are 4 GET requests shown below that record the background updates that Firefox was doing for itself. The first 3 of these requests resulted in HTTP redirect 302 and 301 responses from the server(s) they contacted. The 4th of these requests got an HTTP status 200 response, which generated 44,853 bytes of data from the server to the Firefox client-side app.

The last of the GET requests shown here was the one initiated by the curl client-side app, and it is shown to have generated a 13 bytes response (the returned IP address). Also shown is some important details about the server certificate.





Clicking on this last GET request from curl produces a second-level detail display, showing decrypted versions of all sent and received HTTP headers, full details about the server certificate, and ...





... the decrypted contents of the server response, as shown below under the “CONTENT” heading. So, to summarize this point, what this shows is that the proxy is decrypting the HTTPS packets going through it. Normal HTTPS communications are end-to-end encrypted, meaning that only the end points are able to see the decrypted data.





In summary, here are the packets sent between the client-side app and the proxy, as captured by Wireshark:





In summary, here are the packets sent between the proxy and the (outbound) server, as captured by Wireshark:





In summary, here are all the DNS packets sent and received, as captured by Wireshark:





>> Selected Source Code <<

Selected portions of the Project source code for 3 of the key features of the proxy follows: (1) showing how the proxy is able to emulate an HTTPS server to the client-side app; (2) showing how the proxy handles both HTTP and HTTPS traffic; and (3) showing how the proxy decrypts the HTTPS traffic.

First is the listen() function in lib/https_proxy.js which waits for a client-side application to first establish a TCP socket connection and then looks for a data packet which starts with the word CONNECT. At this point the hijackSsl() function is called, passing in a string containing the headers which the client-side app has sent, and the socket descriptor which connects the client-side app to the proxy app.

var proxyName = 'https proxy';//// allowed server ports requested by client (default 443 only)//var httpsProxyAllowedPorts = process.env.CONNECT_ALLOWED_PORTS || 443;//// allowed client user agents to connect to proxy (default null = any)//var httpsProxyAllowedUserAgents = process.env.CONNECT_ALLOWED_USER_AGENTS || null;//// possible state values for client socket/connection to proxy//var STATES = { UNCONNECTED: 0, CONNECTING: 1, CONNECTED: 2};//// define function to create https proxy and listen() event to be triggered// on each client-side connection to it// parameter: listenPort port number to listen for// incoming https client packets// parameter: listenAddress interface IP address to listen for// incoming https client packets// returns: bound tcp net.server() used as https proxy by client-side apps//HttpsProxy.prototype.listen = function (listenPort, listenAddress) { var self = this; var tlsServer = net.createServer(function (clientSocket) { var headers = ''; var data = []; var state = STATES.UNCONNECTED; //





// on connect() logs incoming client connection and sets state // to "connecting" (neither unconnected nor connected) // parameter: clientSocket is socket connected to client-side app // clientSocket.addListener( 'connect', function () { log.debug( util.format('client %s:%d connected to %s port %d', clientSocket.remoteAddress, clientSocket.remotePort, proxyName, listenPort ) ); state = STATES.CONNECTING; return state; } ); // // on data() arriving at https proxy socket from client // ignore incoming data if socket state is already "connected" // if incoming http headers contains 2 \r\n then process headers // if incoming http headers do not start with CONNECT then // log + close socket connection to client // if incoming http headers start with CONNECT then trigger hijackSsl() // return clientSocket.addListener( 'data', function (data) { if (state !== STATES.CONNECTED) { headers += data.toString(); if (headers.match('\r\n\r\n')) { state = STATES.CONNECTED; if (headers.match(/^CONNECT/)) { return self.hijackSsl(headers, clientSocket); } else { log.warn( util.format('unrecognized %s request from client %s:%d', proxyName, clientSocket.remoteAddress, clientSocket.remotePort ) ); log.debug( util.format('unrecognized %s client %s:%d request: %s', proxyName, clientSocket.remoteAddress, clientSocket.remotePort, headers





) ); return clientSocket.end(); } } } } ); }); return tlsServer.listen(listenPort, listenAddress);};

The hijackSsl() function (also in lib/https_proxy.js) consists of the following. First the CONNECT packet is parsed to get the destination host name, port and HTTP protocol version number. Then the destination port number is validated against the port number allowed by the proxy, which defaults to port 443. Then User-Agent is extracted from the CONNECT packet, and validated against the user agent allowed by the proxy, which defaults to any user agent. Then the genCert.build() function is called, passing in the clientRequestHostname to ensure the automatically generated certificate is created for the proper host, and returning a tlsContext object. The tlsContext object is used in the tls.createSecurePair() function to create the critical “pair”[94] stream object. The pair stream object is in turn used in the hijackPipe() function which is described after this section.

//// define proxy function to trigger on incoming client HTTP CONNECT packet// parameter: headers string of http request from client// parameter: clientSocket proxy socket number connected to client// returns: nothing//HttpsProxy.prototype.hijackSsl = function (headers, clientSocket) { var _this = this; var match = headers.match('CONNECT +([^:]+):([0-9]+).*'); if (!match || match.length < 2) { // // if invalid client header then log, close socket and abort // header must be HTTP CONNECT packet which identifies remote // https server and port (usually port 443) // and optionally specifies http version // log.warn( util.format( 'invalid CONNECT request received by %s from client %s:%d', proxyName, clientSocket.remoteAddress, clientSocket.remotePort ) ); return clientSocket.end(); }





clientRequestPort ) ); return clientSocket.end(); } // // trigger build() function in gencert.js // to get or create TLS/SSL certificate for specified host name // parameter: proxyName which in this context is 'https proxy' // parameter: clientRequestHostname https server hostname // requested by client and which is used to generate intermediate // SSL/TLS certificate // parameter: completion cb function // returns: result of clientSocket.write() or null // return genCert.build( proxyName, clientRequestHostname, function (tlsContext) { if (!tlsContext || tlsContext === null) { return null; } var isServer = true; var requestClientCert = false; var allowUnauthorizedClient = false; var pair = tls.createSecurePair( tlsContext, isServer, requestClientCert, allowUnauthorizedClient ); // // xxx: if this fails, or proxy cert has expired, need to // force creation of new clientRequestHostname cert // do getPeerCertificate() here somewhere // var httpServer = new http.Server(); httpServer.addListener('request', _this.handle); var clientCleartextStream = hijackPipe(pair, clientSocket); http._connectionListener.call(_this, clientCleartextStream); _this.httpAllowHalfOpen = false; log.info( util.format( 'client %s:%d (ua %s) connecting through %s to server %s', clientSocket.remoteAddress, clientSocket.remotePort, clientRequestUserAgentArray[0], proxyName, clientRequestHostname )





); return clientSocket.write( clientRequestHttpVersion + ' 200 Connection established\r\n' + 'Proxy-agent: Proxyup\r\n\r\n' ); } );};

The hijackPipe() function (also in lib/https_proxy.js) consists of the following node.js magic. I refer to this as magic because it hides all the complexity of managing an encrypted data stream to and from the client and the server. Also, it is not yet well documented in node. The pipe()[95] function, in particular, is both mysterious and wonderful.

//// define hijackPipe() function to setup event triggers on socket connection// to client and to setup ClearTextStream object associated with it// parameter: pair SecurePair object// parameter: socket on proxy connected to client-side socket// returns: ClearTextStream object//var hijackPipe = function (pair, socket) { var clientStream = pair.encrypted.pipe(socket); var serverStream = socket.pipe(pair.encrypted); pair.fd = socket.fd; var clearText = pair.cleartext; clearText.socket = socket; clearText.encrypted = pair.encrypted; clearText.authorized = false; var onError = function (e) { if (clearText._controlReleased) { return clearText.emit('error', e); } else { return e; // xxx: really? } }; var onTimeout = function () { return clearText.emit('timeout'); }; var onClose = function () { socket.removeListener('error', onError); socket.removeListener('close', onClose); return socket.removeListener('timeout', onTimeout); }; var onData = function (data) { if (pair.encrypted.pair._secureEstablished) { return log.debug( util.format( 'client %s:%d server %s data event (%d bytes): secure %j',





socket.remoteAddress, socket.remotePort, pair.encrypted.pair.servername, data.length, pair.encrypted.pair.ssl ) ); } else { return log.debug( util.format( 'client %s:%d server %s data event (%d bytes): not secure', socket.remoteAddress, socket.remotePort, pair.encrypted.pair.servername, data.length ) ); } }; socket.on('error', onError); socket.on('close', onClose); socket.on('timeout', onTimeout); socket.on('data', onData); return clearText;};

The genCert.build() function (in lib/gencert.js) referenced inside hijackSsl() consists of the following. It first uses getCerts() to see if the certificate already exists. If so, it returns it. If not, does a chain.add() to fork a separate process to execute the createCerts() function.

//// build() function to create new SSL/TLS cert and key for given hostname// unless already in cache, in which case they are used// parameter: proxyName for logging purposes only// parameter: hostname to use for intermediate SSL/TLS cert// parameter: completion cb function to pass tlsCredentials// returned by getCerts()// returns: results of completionCallback()//exports.build = function (proxyName, host, completionCallback) { // // xxx: need new incoming parameter to force creation of new cert // rather than looking it up first in cache // "use strict"; var qCompletionCallback; var qName; var qJob; var tlsCredentials = getCerts(proxyName, host);





if (tlsCredentials) { // // found credentials in local cache - pass them to completionCallback() // return completionCallback(tlsCredentials); } else { // // create new intermediate cert and key credentials for this host // to be used by the proxy // log.debug( util.format('queuing up %s cert gen for %s', proxyName, host ) ); qName = host + ' genCert'; qCompletionCallback = function (err) { return completionCallback(getCerts(proxyName, host)); }; // // define qJob() to be added to queue // @param: proxyName for logging purposes // @param: host name to generate credentials for // qJob = function (proxyName, host) { return function (worker) { return createCerts( proxyName, host, function () { return worker.finish(); } ); }; }; // // add qJob() to queue // return chain.add(qJob(proxyName, host), qName, qCompletionCallback); }};

The getCerts() function (also in lib/gencert.js) checks to see if a certificate and key file have already been generated and saved.

//// define getCerts() function to read existing SSL/TLS certs from local cache// in order to create TLS credentials object





// @param proxyName for logging purposes only// @param host is domain name associated with certs// @returns false if no key or no cert exists for this host in local cache// @returns TLS credentials object if key and cert do exist in local cache// for this host//var getCerts = function (proxyName, host) { "use strict"; log.debug( util.format('%s getCerts(%s) looking for certs in %s', proxyName, host, CERTS_DIR ) ); var hostKeyFilename = CERTS_DIR + SEP + host + '.key'; var hostCertFilename = CERTS_DIR + SEP + host + '.crt'; var caFilename = CA_DIR + SEP + 'ca.crt'; // // xxx: make async/nonblocking cache reads of key and cert? // if (path.existsSync(hostKeyFilename) && path.existsSync(hostCertFilename) ) { // // read key and crt files from cache // xxx: make async/non-blocking rather than sync/blocking? // xxx: must check expiry date(s) and reject if necessary // var hostKey = fs.readFileSync(hostKeyFilename, 'ascii'); var hostCert = fs.readFileSync(hostCertFilename, 'ascii'); // // xxx: why only these ciphers? how change? // xxx: why not being used in crypto.createCredentials()? // var hostCiphers = 'RC4-SHA:AES128-SHA:AES256-SHA'; var tlsSettings; log.debug( util.format('%s %s key (%d bytes) and cert (%d bytes) found', proxyName, host, hostKey.length, hostCert.length ) ); if (path.existsSync(caFilename)) { // // self-signed cert authority exists in local cache // xxx: make async/nonblocking? // xxx: what if not self-signed ca? any problems? // xxx: update design to allow host-specific ca? // var certAuth = fs.readFileSync(caFilename, 'ascii');





log.debug( util.format('%s cert auth for %s found (%d bytes)', proxyName, host, certAuth.length ) ); tlsSettings = crypto.createCredentials( {key: hostKey, cert: hostCert, ca: certAuth} // could add ciphers: hostCiphers ); } else { // // ca not found - use system default trusted cert auths instead // tlsSettings = crypto.createCredentials( {key: hostKey, cert: hostCert} // could add ciphers: hostCiphers ); } // // ah - ciphers are defined here // tlsSettings.context.setCiphers(hostCiphers); return tlsSettings; } else { // // one or both of key or crt file not found in cache // return false; }};

The createCerts() function (also in lib/gencert.js) is where certificates are generated. The statGenScript() function is called first, which triggers the chmodGenScript() function to be called, which forks a child process with spawn() to execute the gencert.sh script.

//// define createCerts() function to create intermediate SSL/TLS certificate and// key files in local cache// @param proxyName for logging purposes only// @param host is domain name// @param completionCallback pointer// @returns completionCallback(certs) or completionCallback(false)//var createCerts = function (proxyName, host, completionCallback) { "use strict"; var cachedCredentials = getCerts(proxyName, host); if (cachedCredentials) { // // credentials already in local cache





// use them instead of creating new // log.debug( util.format('found host %s existing certs for %s', host, proxyName ) ); return completionCallback(cachedCredentials); } else { // // credentials not found - create them now and save in local cache // xxx: get following from geoip/geolite // var countryCode = process.env.COUNTRYCODE || process.env.CC || 'CA'; var stateCode = process.env.STATECODE || process.env.PROVINCECODE || 'BC'; var stateName = process.env.STATENAME || process.env.PROVINCENAME || 'British Columbia'; var cityName = process.env.CITY || process.env.LOCALITY || 'Vancouver'; // // xxx: fix magic names // var orgName = process.env.ORG || 'Securikai'; var orgUnit = process.env.OU || 'proxyup'; // // default 30 days before generated host certs expire // xxx: must validate // var hostCertDays = process.env.HOST_CERT_EXPIRY_DAYS || '30'; var childProcess; // // gencert.sh script contains openssl commands to create // key and crt and ca files // var genScript = __dirname + SEP + 'bin' + SEP + 'gencert.sh'; var newMod = '0755'; // +x // // define chmodGenScript() function to do completion cb on async fs.chmod() // @param: err is error returned by fs.chmod() (if any) // @param: stats is fs.Stats object returned by fs.chmod() // @returns: nothing // var chmodGenScript = function (err, stats) { if (err) { log.error( util.format( 'unable to chmod %s in %s to gen certs for %s to use ' + 'for host %s: %s', newMod, genScript,





proxyName, host, err.message ) ); } else { log.debug( util.format('generating certs for %s to use for host %s', proxyName, host ) ); // // spawn() a forked process to run genScript shell script // with array of parameters // @param: genScript name is shell script to run // @param: array of parameters to pass to script // @returns: child pid // childProcess = spawn( genScript, [host, Date.now(), mainDir, countryCode, stateName, cityName, orgName, orgUnit, hostCertDays] ); // // define cb on exit of child process // @param: code is exit code of child process // @param: signal is signal causing exit of child process (if any) // @returns: completionCallback() on getCerts() // that were assumed to be created by the child process // childProcess.on('exit', function (code, signal) { if (code) { log.error( util.format( 'error generating cert for %s to use for host %s: %s', proxyName, host, signal ) ); return completionCallback(false); } else { return completionCallback(getCerts(proxyName, host)); } } ); } };





// // define statGenScript() function to do completion cb on async fs.stat() // @param: err is error returned by fs.stat() (if any) // @param: stats is fs.Stats object returned by fs.stat() // @returns: nothing // var statGenScript = function (err, stats) { if (err) { log.error( util.format( 'unable to stat %s to gen certs for %s to use for host %s: %s', genScript, proxyName, host, err.message ) ); } else { // // make sure script is executable // fs.chmod(genScript, newMod, chmodGenScript); } }; // // make sure script can be found // fs.stat(genScript, statGenScript); }};

The gencert.sh script (in lib/bin) is where self-signed certificates and keys - as well as the self-signed certificate authority - are generated using openssl commands. The default is for self-signed certificates to be valid for 30 days, the certificate authority for 10 years. Most of the parameters are passed in as arguments from the gencert.js createCerts() function show above.

#!/bin/sh# @file gencert.sh# @project proxyup# @author Wesley Kenzie ([email protected] GPG 0x831b2c89)# @version 0.2.26# @created 2012-01-25# @based on certgen.sh by Mark Percival ([email protected])# as part of middlefiddle project.# @modified 2012-02-11# @copyright 2012 Wesley Kenzie. See COPYRIGHT file.# @copyright 2011 Mark Percival. See LICENSE-middlefiddle file.# @license MIT. See LICENSE* file(s).# xxx: move all this functionality into node for portability and more









version="0.2.26"ca_keylen="2048"host_cert_keylen="2048"ca_cert_days="3650"host_cert_days="$9"dir0=$3serial=$2cert_dir="$dir0/certs"ca_key_file="$dir0/ca.key"ca_crt_file="$dir0/ca.crt"cert_key_file="$cert_dir/$1.key"cert_csr_file="$cert_dir/$1.csr"cert_crt_file="$cert_dir/$1.crt"ccode=$4stcode=$5locname=$6org=$7orgunit="$8 on `hostname`"ca_domain="Securikai"logdir="$dir0/logs"log="$logdir/$1_gencert.log"

if [ ! -d $logdir ]; then mkdir -p "$logdir"fiif [ ! -d $logdir ]; then echo "$0 unable to create log dir $logdir"fi

echo "[start] $0 v$version at `date` ---" >"$log"echo `hostname` >>"$log"if [ ! -e $ca_key_file ]; then echo "creating self-signed ca key and cert in $dir0" >>"$log" mkdir -p "$dir0" >>"$log" 2>&1 openssl genrsa \ -out $ca_key_file "$ca_keylen" \ >>"$log" 2>&1 chmod 400 $ca_key_file >>"$log" 2>&1 openssl req -new \ -x509 \ -days "$ca_cert_days" \ -key $ca_key_file \ -out $ca_crt_file \ -subj \ "/C=$ccode/ST=$stcode/L=$locname/O=$org/OU=$orgunit/CN=$ca_domain CA" \ >>"$log" 2>&1fi

# Setup the server keyif [ ! -e $cert_key_file ]; then





echo "creating self-signed server key and cert in $cert_dir" >>"$log" mkdir -p "$cert_dir" >>"$log" 2>&1 openssl genrsa \ -out $cert_key_file "$host_cert_keylen" \ >>"$log" 2>&1 chmod 400 $cert_key_file >>"$log" 2>&1 openssl req -new \ -key $cert_key_file \ -out $cert_csr_file \ -subj \ "/C=$ccode/ST=$stcode/L=$locname/O=$org/OU=$orgunit/CN=$1" \ >>"$log" 2>&1 # Sign with the CA openssl x509 -req \ -days "$host_cert_days" \ -in $cert_csr_file \ -CA $ca_crt_file \ -CAkey $ca_key_file \ -set_serial $serial \ -out $cert_crt_file \ >>"$log" 2>&1fiecho "[end] $0 v$version at `date` ---" >>"$log"

The proxyToServer() function (in lib/http_proxy.js) shown below is where the HTTP packets are sent and received. The “req” variable is a client-side HTTP request object coming into the proxy, “res” is a server HTTP response object going to the client-side app, “upstream_request” is an HTTP request object going out of the proxy to the remote server, and “upstream_res” is a remote server HTTP response object coming from the remote server.

//// define proxyToServer() function to define how and when data is sent// from the proxy to the remote/upstream server// @param: req client http request object// @param: res server http response object// @param: next not applicable// @returns: nothing//HttpProxy.prototype.proxyToServer = function (req, res, next) { var upstream_processor, upstream_request; req.startTime = new Date(); var passed_opts = { method: req.method, path: req.url, host: req.host, headers: req.headers, port: req.port }; //





// define upstream_processor() function to populate downstream client-side // http response object // @param: upstream_res is remote server http response object // @returns: nothing // upstream_processor = function (upstream_res) { res.statusCode = upstream_res.statusCode; res.headers = upstream_res.headers; res.modifyResponseHeaders(); if (res.headers && res.headers['content-type'] && res.headers['content-type'].search(/(text)|(application)/) >= 0) { // // if http response is text or application then set as not binary // res.isBinary = false; } else { res.isBinary = true; } responseBodyLogger(res); // // write http headers to downstream client-side app // res.writeHead(upstream_res.statusCode, upstream_res.headers); log.quiet('[http_proxy upstream_processor] response socket pair ' + util.inspect(res.socket.pair, true, 1, true)); // if (upstream_res.socket.pair && upstream_res.socket.pair._secureEstablished !== undefined && upstream_res.socket.pair._secureEstablished && res.socket.pair.servername) { // // get then log upstream remote server SSL/TLS cert // xxx: also need to validate cert here and abort sending downstream // to client if validation fails // res.serverCert = require('proxyup.js').validateServerCert( res.socket.pair.servername, upstream_res.socket.pair.cleartext ); log.debug('server TLS/SSL cert: ' + JSON.stringify(res.serverCert)); } upstream_res.on( 'data', function (chunk) { res.write(chunk, 'binary'); if (res.socket.pair) { log.quiet( util.format( 'response status %d ' +





'data chunk with headers %j for %s:%d (from %s)', res.statusCode, res.headers, res.socket.remoteAddress, res.socket.remotePort, res.socket.pair.servername ) ); } return res.emit('data', chunk); } ); upstream_res.on( 'end', function (data) { res.endTime = new Date(); res.end(data); return res.emit('end'); } ); upstream_res.on( 'close', function () { return res.emit('close'); } ); return upstream_res.on( 'error', function () { return res.abort(); } ); }; req.on( 'data', function (chunk) { log.quiet( util.format( '%s request to %s chunk data', req.method, req.fullUrl ) ); return upstream_request.write(chunk); } ); req.on( 'error', function (err) { log.error(





util.format( 'unable to %s request to %s:%d: %s', req.method, req.host, req.port, err.message ) ); return res.end(); } ); if (req.ssl) { upstream_request = https.request(passed_opts, upstream_processor); log.debug( util.format( 'https request headers: %j', upstream_request._headers ) ); } else { upstream_request = http.request(passed_opts, upstream_processor); log.debug( util.format( 'http request headers: %j', upstream_request._headers ) ); } upstream_request.on( 'error', function (err) { log.error( util.format( 'unable to process upstream %s request to %s:%d: %s', req.method, req.host, req.port, err.message ) ); return res.end(); } ); return upstream_request.end();};





(ii) Use Case Diagrams/Analysis

The following Use Case Diagram shows the client-side application getting or setting its proxy settings; sending a CONNECT request packet to the proxyup application; establishing an HTTPS connection between the proxyup application and the web server; establishing an HTTPS connection between the proxyup application and the client-side application; capturing request and response headers and content for the Middleware Console; and displaying request and response headers and contents by the Middleware Console.





(iii) Sequence Diagram

The following Sequence Diagram shows how the various objects collaborate along a timeline to ensure a Client-side app can communicate through the Proxyup app with a Web Server.





(iv) Class Diagram

The following Class Diagram shows the classes and relationships among them. There can be any number of client-side applications making socket connections to the 1 Proxyup application, which negotiates the required socket connections with any number of outbound HTTP (and HTTPS) servers. Once the socket connections are in place, and if necessary, the TLS/SSL protocol, then the client-side app sends GET or POST HTTP Requests to the Proxyup app, which are forwarded to the appropriate HTTP or HTTPS server. The server sends back HTTP Responses to the Proxyup app, which are then forwarded to the appropriate client-side app. The TLS Middleware Console reads data saved by the Proxyup app, and displays them in the browser.





(v) Object Diagram

The following Object Diagram shows some of the instantiations of each Class. The Proxyup App, Proxyup Certificate Authority and TLS Middleware Console are omitted here because there is only ever 1 instance of each.





(vi) Collaboration Diagram

The following Collaboration Diagram shows the interactions between various object instances to ensure a Client-side Firefox app can communicate through the Proxyup app with the ippages.com Web Server.





2(f) Implementation Implications

Many implementation issues concerning use of this Project’s proxyup application are shared with all users of HTTP and HTTPS proxies. How are client-side applications to be configured to use it? Which client-side apps are to be configured? What about other client-side apps? Is the user aware of the proxy? What are the reasons for having the proxy in place? Is there a system administrator who has responsibility for setup and operation of the proxy? What organizational policies are in place concerning the proxy? What firewall policies exist? What firewall policies need to be changed? What choices are available to the user when the proxy fails? What consequences does the user face when circumventing the proxy? Is use of the proxy voluntary? Mandatory? Optional? What privacy laws and regulations must be adhered to? Who will be monitoring the proxy logs? What data will the proxy send to its logs? What happens to the proxy logs after they are created? What potential actions might be taken, or potential decisions made, based on information found in the proxy logs? Who will be patching and updating the proxy when needed? What proxy documentation and knowledge base is to be maintained?

Most of these considerations are beyond the scope of this Practicum Project. There are very substantial operational, legal, and ethical issues that need to be responsibly considered when using the proxy developed for this Project, but the author is not able to address these in a comprehensive way. USERS OF THIS PROJECT’S PROXYUP SOFTWARE ARE STRONGLY RECOMMENDED TO CONSULT WITH THEIR OWN LEGAL AND ORGANIZATIONAL RESOURCES BEFORE USING THE SOFTWARE FOR ANYTHING OTHER THAN PERSONAL USE. The decryption of HTTPS and TLS/SSL communications, in particular, is a capability of the proxyup app that could introduce liability of some sort due to its encroachment on what is usually considered to be private and confidential communication.

The implementation implications are discussed here for 3 Use Cases: Single-User, Local Subnet, and Organizational.

For the Single-User Use Case it is assumed that the end user is aware of the proxy app when in use, and is a willing participant in setting it up and managing it. For the Local Subnet Use Case it is assumed that each end user on the subnet is aware of the shared proxy app when in use, is a willing participant in setting up their own client-side apps to use it, and understands all the implications of their HTTPS communications being decrypted by the proxy app. For the Organizational Use Case it is assumed that each end user in the organization is aware of the shared proxy app when in use, is aware of the delineation between their own rights and the organization’s rights with regards to their HTTP and HTTPS communications, and is a willing participant in setting up their own client-side apps to use it.

(i) Configuration

In order for a user’s client-side application to make use of the proxyup application, in the Single-User Use Case, node.js must first be installed. There is a Windows and Macintosh installer available at http://nodejs.org as well as a source code tar ball for building your own node.js



http://nodejs.org/#

http://nodejs.org/#



executable. The standard OpenSSL[20] library must also be installed for the proxyup app to be able to process HTTPS connections. The proxyup app files are available on its public repository at https://launchpad.net/proxyup.

Once started, the proxy app runs as a background process/service listening on port 8080 for incoming client-side app HTTP connections, and on port 8443 for incoming client-side app HTTPS connections.

Each client-side app must be manually configured to use the proxy. In the case of a current (version 10.0.1) Mozilla Firefox for 64-bit Ubuntu 10, this configuration is done under the Edit | Preferences menu item as shown below:







On the Advanced | Network tab are the following settings where the “HTTP Proxy” and “SSL Proxy” settings are made. The “127.0.0.1” IP address simply indicates that the proxy app is running on the same machine as the client-side apps.

After the OK and Close buttons are clicked, the Firefox browser in this example will use the proxyup app for its HTTP and HTTPS connections. Other client-side applications, however, would need to be configured in their own ways to accomplish this.





For the Local Subnet Use Case, node.js would only be required on the device where the proxyup app would be running - not on each client workstation. Configuration of client-side apps would be accomplished by setting the “HTTP Proxy” and “SSL Proxy” settings in Firefox as shown below. The IP address 192.168.0.99 in this example would identify the private IP address of the device where the proxyup app would be running. It is presumed that destination ports 8080 and 8443 would be open/available through the firewall of each client workstation, and incoming connections allowed to these same ports on the 192.168.0.99 device where the proxyup app is running.





For the Organizational Use Case, node.js would again only be required on the server where the proxyup app would be running - and not on each client workstation. Configuration of client-side apps would be accomplished by setting the “HTTP Proxy” and “SSL Proxy” settings in Firefox as shown below. The IP addresses 212.117.170.55 and 212.117.175.195 in this example would identify the public IP address of the servers where the proxyup app would be running. These obviously could be the same server, rather than different ones as shown in this example. This configuration would allow client workstations in various locations to all access the same instance of the proxyup app, although there would also be a need for authentication in this Use Case, to restrict access to only authorized users.





(ii) Logging

By default, the proxyup app logs to the /var/log/proxyup.log file with level “info”. The amount of information logged can be specified by setting and exporting the LOGLEVEL environment variable before the proxyup app is started. Logging will be disabled if LOGLEVEL is set to “quiet”, and increasing quantities of information will be logged at levels “error”, or “warning”, or “info”, or “debug”.

Logging can be done to an alternative log directory or log filename by setting and exporting the LOG_DIRECTORY and LOG_FILENAME environment variables before the proxyup app is started.

Logging is currently done synchronously to disk (i.e. “blocking”), rather than asynchronously (“non-blocking”), and therefore it is expected to have a material impact on performance in high-throughput situations, especially with logging levels of “info” or “debug”. Changing logging to be done asynchronously is planned as a future enhancement to address this potential bottleneck.

(iii) Middleware Observation

By default, the proxyup app observes all HTTP and HTTPS traffic passing through it. The HTTPS traffic is observed as decrypted. Observation is accomplished in real-time by a “Proxyup TLS Middleware” browser-based console running on port 8115 of the same device running the proxyup app. Each client-side app request and corresponding server response is displayed together, in a ring buffer summary format that can be clicked to get more details about each individual summary entry. Middleware Observation is a separate function from logging, and each records different data elements.

It is expected that middleware observation of all traffic may have a material impact on performance in high-throughput situations though no measurements have been made as yet to test this hypothesis. The proxyup app does support regex filtering of observed request hostname, and of responses containing any string in its html “body” section, which allows for relatively fine grained control of how much data is made available for observation. This functionality is not well tested at this point however.

(iv) IPv6

The node.js platform[60][61][62] supports both IPv4 and IPv6[85] connections natively, but IPv6 has not yet been tested for this Project. The default listening IPv4 address for both HTTP and HTTPS connections is 127.0.0.1 but these can be overridden by setting and exporting the HTTP_LISTEN_IP and/or HTTPS_LISTEN_IP environment variables before startup.





(v) Certificate Trust

The proxyup app automatically generates its own self-signed TLS/SSL certificates for each hostname a client-side app attempts to make a HTTPS connection to. It saves each of these certificates to disk for subsequent use. It also generates (just once) a single self-signed certificate authority (“CA”) private key and certificate (and saves them to disk) and uses them for generating the hostname certificates. The self-signed CA files are not going to be part of any standard CA “chain of trust”, and so any client-side app will consider the proxyup app’s certificates to be untrusted/insecure[3]. This means that each client-side app should/will throw an alert when presented with these hostname certificates. If the user has a choice to add an exception to this condition, and that choice is taken, then the certificate alert would then be ignored by the client-side app until the certificate expires, or until a different certificate is presented. A different certificate would possibly/likely indicate a man-in-the-middle attack, and it is this condition which the proxyup app is intended and designed to handle in such a way that the user is better protected. In its current form, however, the proxyup app does not handle this condition any better than any standard client-side app other than setting an arbitrarily short expiry period so that the issue of certificate authenticity is kept relatively “front of mind”.

The TLS/SSL hostname certificates are set to expire 30 days after creation, but this expiry period can be overridden by setting and exporting the HOST_CERT_EXPIRY_DAYS environment variable to a different number of days, such as 365 to keep them for a year, or 2 to have them expire after only 2 days.

The CA certificate is set to expire in 10 years, and this cannot currently be changed by the proxyup app user. It is intended to be more or less permanent.

2(g) Applicable New Technology Research

The primary focus of this Project has been to discover a way to create a proxy that can be inserted into normally end-to-end encrypted HTTPS communications. A standard HTTP CONNECT proxy with suitable http parsing functionality was discovered to be able to accomplish this, but it was the discovery of “pair” streams in the node.js platform[60][61][62] that also allowed for dynamic decryption of the HTTPS stream.

Additional research is planned, as indicated in section 2(i) Future Enhancements.

2(h) Milestones and Deliverables

Milestone Deliverable Status Actual Hours0 Delivery of detailed design specification. unfinished 60 Target date: March 31, 2011

Milestone Deliverable Status Actual Hours1 Delivery of version 0.1 completed 480 as per Evolutionary Delivery Lifecycle step (1):





Support for a single-user Firefox secure connection through the proxy over IPv4 using one of the supported TLS or SSL versions, a single Cipher Suite, TCP, HTTPS, and a valid server certificate.

Milestone Deliverable Status Actual Hours2 Delivery of version 0.1.1 completed 32 as per Evolutionary Delivery Lifecycle step (2): Addition of support for local logging.

Milestone Deliverable Status Actual Hours3 Delivery of version 0.1.2 not started 0 as per Evolutionary Delivery Lifecycle step (3): Addition of support for a local data store.

Milestone Deliverable Status Actual Hours4 Delivery of version 0.2 unfinished 18 as per Evolutionary Delivery Lifecycle step (4): Addition of support for invalid server certificates.

Milestone Deliverable Status Actual Hours5 Delivery of version 0.2.1 not started 0 as per Evolutionary Delivery Lifecycle step (5): Addition of support for additional Cipher Suites.

Milestone Deliverable Status Actual Hours6 Delivery of version 0.2.2 not started 0 as per Evolutionary Delivery Lifecycle step (6): Addition of support for additional TLS and SSL versions.

Milestone Deliverable Status Actual Hours7 Delivery of version 0.3 unfinished 2 as per Evolutionary Delivery Lifecycle step (7): Addition of support for IPv6[85] connections.

Milestone Deliverable Status Actual Hours8 Delivery of version 0.4 deferred 0 as per Evolutionary Delivery Lifecycle step (8): Addition of support for secure UDP connections using DTLS[25][52].

Milestone Deliverable Status Actual Hours9 Delivery of version 0.5 unfinished 4





as per Evolutionary Delivery Lifecycle step (9): Addition of support for expiring server certificates.

Milestone Deliverable Status Actual Hours10 Delivery of version 0.6 not started 0 as per Evolutionary Delivery Lifecycle step (10): Addition of support for revoked server certificates.

Milestone Deliverable Status Actual Hours11 Delivery of version 0.7 completed 2 as per Evolutionary Delivery Lifecycle step (11): Addition of support for multiple simultaneous client-side applications.

Milestone Deliverable Status Actual Hours12 Delivery of version 0.8 unfinished 2 as per Evolutionary Delivery Lifecycle step (12): Addition of support for multiple users.

Milestone Deliverable Status Actual Hours13 Delivery of version 0.9 not started 0 as per Evolutionary Delivery Lifecycle step (13): Addition of support for local caching of static objects.

Milestone Deliverable Status Actual Hours14 Delivery of version 1.0 not started 0 Target date: December 31, 2011 as per Evolutionary Delivery Lifecycle step (14): Addition of support for remote data store.

Milestone Deliverable Status Actual Hours15 Optional Delivery deferred 0 as per Evolutionary Delivery Lifecycle step (15): Addition of support for distributed data stores.

Milestone Deliverable Status Actual Hours16 Optional Delivery deferred 0 as per Evolutionary Delivery Lifecycle step (16): Addition of support for remote or distributed caching.

Milestone Deliverable Status Actual Hours17 Optional Delivery deferred 0 as per Evolutionary Delivery Lifecycle step (17): Addition of support for remote logging.





Milestones completed: 3Milestones unfinished: 5Milestones not started: 6Milestones deferred: 4Total Actual Hours: 580

2(i) Future Enhancements

There are a significant number of enhancements planned for this Project’s proxyup software application as follows:

(i) Shorter Term- support for proxying of the SSH (“secure shell”) protocol- support for proxying of DNS (“domain name system”) protocol- support for proxy.pac auto-configuration files- support for proxying HTTP and HTTPS out to the Tor[31] network and back- support for proxying HTTP and HTTPS out to SOCKS4a[88] proxy and back- support for proxying HTTP and HTTPS out to SOCKS5[89] proxy and back- creation of proxy self-signed certificates based on actual server certificate details (such as from/

to dates)- better handling of self-signed certificate changes encountered- asynchronous non-blocking logging to disk- support for logging to syslog- availability as a node.js package manager (“npm”) module- support for auto-updating via “npm update” functionality on a user-defined schedule- option to keep persistent store of server certificate data in Apache CouchDB[78], MongoDB[79],

Redis[80], or Apache Cassandra[16][86] database- support for local caching of static files similar to Polipo[17] or Tinyproxy[18]

- use of certificate trust notaries as specified by the Perspectives Project[49] and Convergence[50]

- availability on Microsoft Windows™ Server and client platforms- availability on Apple OS X platform- support for simultaneous IPv4 and IPv6 HTTP and HTTPS connections- configurable Cipher Suites: current setting uses RC4-SHA, AES128-SHA, AES256-SHA- configurable SSL and TLS versions: unknown current settings- configurable hash functions: unknown current settings

(ii) Longer Term- support for proxying of the DTLS[25][52] protocol (TLS secure wrapper for UDP datagrams)- support for stunnel[12][13]-like wrapping of HTTP connections- support for Tor Obfsproxy[82] functionality to resist TLS/SSL filtering by third parties- use of certificate auditing functionality as proposed by Google[75]

- support for OpenVPN[81] clients- execution in JavaScript-enabled browsers similar in concept to Flash Proxies[51]





- bilateral authentication, where client certificates are sent to the server for authentication before the TLS/SSL connection can be established

- support for automated, background checks for self-updates, either via npm or embedded in proxyup app





3. CONCLUSIONS

This Practicum Project has successfully developed a highly scalable, highly portable proxy software application which provides proxy services for both HTTP and HTTPS communications, and which dynamically decrypts the HTTPS data stream for analysis without interrupting either the client or the server. The proxy app is available as an open source project at https://launchpad.net/proxyup and it is the author’s intention to develop it further with a number of significant enhancements. The primary focus will be to establish the proxy as a foundation for increasing the security and privacy of users while using the Internet. By encapsulating TLS/SSL processing in the proxy app, client-side applications will be better able to have protection against the inherent “trust” weakness in the current design of secure communications today.







4. APPENDIX

4(a). Bibliography

[1] Edge, Jake. Security: Trust, but Verify. Reference found on “LWN.net” Internet site at http://lwn.net/Articles/373988/ on October 28, 2010 and on February 13, 2012.

[2] Schneier, Bruce and Ellison, Carl. Ten Risks of PKI: What You’re not Being Told about Public Key Infrastructure. Reference found on “Schneier on Security” Internet site at http://www.schneier.com/paper-pki-ft.txt on October 29, 2010 and on February 13, 2012.

[3] Lewman, Andrew. Life without a CA. Reference found on “The Tor Project” Internet site at https://blog.torproject.org/blog/life-without-ca on October 29, 2010 and on February 13, 2012.

[4] Fratto, Mike. Yes, Trust In The PKI Is Broken. Reference found on “Information Week” Internet site at http://www.informationweek.com/blog/main/archives/2008/12/yes_trust_in_th.html on October 29, 2010 and on February 13, 2012.

[5] Soghoian, Christopher and Stamm, Sid. Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL. Reference found on “The 10th Privacy Enhancing Technologies Symposium” Internet site at http://petsymposium.org/2010/papers/hotpets10-Soghoian.pdf on October 29, 2010 and on February 13, 2012.

[6] Gutmann, Peter. Everything you Never Wanted to Know about PKI but were Forced to Find Out. Reference found on “The University of Auckland Computer Science” Internet web site at http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf on October 29, 2010 and on February 13, 2012.

[7] Gutmann, Peter. Plug-and-Play PKI: A PKI your Mother can Use. Reference found on “The University of Auckland Computer Science” Internet web site at http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix03.pdf on October 29, 2010 and on February 13, 2012.

[8] Gutmann, Peter. Oops! Defending Where the Attacker Isn’t. Reference found on “The University of Auckland Computer Science” Internet web site at http://www.cs.auckland.ac.nz/~pgut001/pubs/defending.pdf on October 29, 2010 and on February 13, 2012.

[9] TrueCrypt: Free Open-Source On-the-Fly Encryption. Reference found on “TrueCrypt” Internet site at http://www.truecrypt.org/ on October 30, 2010 and on February 13, 2012.

[10] Warner, Brian and Wilcox-O’Hearn, Zooko and Kinninmont, Rob. Tahoe: A Secure Distributed Filesystem. Reference found on “Tahoe-LAFS” Internet site at http://tahoe-lafs.org/trac/tahoe-lafs on October 30, 2010 and on February 13, 2012.



http://lwn.net/Articles/373988/




http://www.schneier.com/paper-pki-ft.txt




https://blog.torproject.org/blog/life-without-ca

https://blog.torproject.org/blog/life-without-ca

http://www.informationweek.com/blog/main/archives/2008/12/yes_trust_in_th.html

http://www.informationweek.com/blog/main/archives/2008/12/yes_trust_in_th.html

http://petsymposium.org/2010/papers/hotpets10-Soghoian.pdf

http://petsymposium.org/2010/papers/hotpets10-Soghoian.pdf

http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix03.pdf




http://www.cs.auckland.ac.nz/~pgut001/pubs/defending.pdf




http://www.truecrypt.org

http://www.truecrypt.org

http://tahoe-lafs.org/trac/tahoe-lafs

http://tahoe-lafs.org/trac/tahoe-lafs



[11] Tor: Hidden Service Protocol. Reference found on “torproject.org” Internet site at https://www.torproject.org/docs/hidden-services.html.en on October 29, 2010 and on February 13, 2012.

[12] stunnel – multiplatform SSL tunneling proxy. Reference found on “mirt.net” Internet site at http://stunnel.mirt.org/ on October 30, 2010 but not on February 13, 2012.

[13] Stunnel – Universal SSL Wrapper. Reference found on “stunnel.org” Internet site at http://www.stunnel.org/ on October 30, 2010 and on February 13, 2012.

[14] OnionCat: An IP-Transparent Tor Hidden Service Connector. Reference found on “cypherpunk.at” Internet site at http://www.cypherpunk.at/onioncat/ on October 30, 2010 and on February 13, 2012.

[15] Distributed hash table. Reference found on “Wikipedia.org” Internet site at http://en.wikipedia.org/wiki/Distributed_hash_table on October 30, 2010 and on February 13, 2012.

[16] The Apache Cassandra Project. Reference found on “apache.org” Internet site at http://cassandra.apache.org/ on October 30, 2010 and on February 13, 2012.

[17] Polipo – a caching web proxy. Reference found on “pps.jussieu.fr” Internet site at http://www.pps.jussieu.fr/~jch/software/polipo/ on October 30, 2010 and on February 13, 2012.

[18] Tinyproxy. Reference found on “banu.com” Internet site at https://banu.com/tinyproxy/ on October 30, 2010 and on February 13, 2012.

[19] The GNU Transport Layer Security Library. Reference found on “gnu.org” Internet site at http://www.gnu.org/software/gnutls/ on October 30, 2010 and on February 13, 2012.

[20] Welcome to the OpenSSL Project. Reference found on “openssl.org” Internet site at http://www.openssl.org/ on October 30, 2010 and on February 13, 2012.

[21] McLoughlin, Mark. The OpenSSL License and the GPL. 2004. Reference found on “gnome.org” Internet site at http://people.gnome.org/~markmc/openssl-and-the-gpl.html on October 30, 2010 and on February 13, 2012.

[22] yaSSL Embedded SSL Library. Reference found on “yassl.com” Internet site at http://yassl.com/yaSSL/Products.html on February 13, 2012.

[23] Thrift. Reference found on “apache.org” Internet site at http://incubator.apache.org/thrift/ on October 30, 2010.

[24] cURL groks URLs. Reference found on “haxx.se” Internet site at http://curl.haxx.se/ on October 30, 2010 and on February 13, 2012.



https://www.torproject.org/docs/hidden-services.html.en




http://stunnel.mirt.org/

http://stunnel.mirt.org/

http://www.stunnel.org/




http://www.cypherpunk.at/onioncat/

http://www.cypherpunk.at/onioncat/

http://en.wikipedia.org/wiki/Distributed_hash_table




http://cassandra.apache.org/




http://www.pps.jussieu.fr/~jch/software/polipo/




https://banu.com/tinyproxy/

https://banu.com/tinyproxy/

http://www.gnu.org/software/gnutls/

http://www.gnu.org/software/gnutls/

http://www.openssl.org/




http://people.gnome.org/~markmc/openssl-and-the-gpl.html

http://people.gnome.org/~markmc/openssl-and-the-gpl.html

http://yassl.com/yaSSL/Products.html




http://incubator.apache.org/thrift/

http://incubator.apache.org/thrift/

http://curl.haxx.se/

http://curl.haxx.se/



[25] Modadugu, Nagendra and Rescorla, Eric. The Design and Implementation of Datagram TLS. Reference found on “stanford.edu” Internet site at http://crypto.stanford.edu/~nagendra/papers/dtls.pdf on October 30, 2010 and on February 12, 2012.

[26] Seagull: an Open Source Multi-protocol Traffic Generator. Reference found on “sourceforge.net” Internet site at http://seagull.sourceforge.net/ on October 30, 2010 and at http://gull.sourceforge.net on February 13, 2012.

[27] hping. Reference found on “hping.org” Internet site at http://www.hping.org/ on October 30, 2010 and on February 13, 2012.

[28] nMap Security Scannner. Reference found on “nmap.org” Internet site at http://nmap.org/ on October 30, 2010 and on February 13, 2012.

[29] Ncat. Reference found on “nmap.org” Internet site at http://nmap.org/ncat/ on October 30, 2010 and on February 13, 2012.

[30] trac Integrated SCM & Project Management. Reference found on “edgewall.org” Internet site at http://trac.edgewall.org/ on October 30, 2010 and on February 13, 2012.

[31] The Tor Project: Anonymity Online. Reference found on “torproject.org” Internet site at https://www.torproject.org/ on October 30, 2010 and on February 13, 2012.

[32] Firefox web browser. Reference found on “Mozilla.com” Internet site at http://www.mozilla.com/firefox/ on October 30, 2010 and at http://www.mozilla.org/en-US/firefox/new/ on February 13, 2012.

[33] Introduction to GNU Wget. Reference found on “gnu.org” Internet site at http://www.gnu.org/software/wget/ on October 30, 2010 and on February 13, 2012.

[34] Wireshark - the world’s foremost network protocol analyzer. Reference found on “Wireshark.org” Internet site at http://www.wireshark.org/ on October 31, 2010 and on February 13, 2012.

[35] Information Technology for Automation Professionals. Chapter 5. TCP/IP Protocol. Protocol Encryption. Reference found on “consultants-online.co.za” Internet site at http://consultants-online.co.za/pub/itap_101/html/ch05s06.html on November 4, 2010 and on February 13, 2012.

[36] Mathewson, Nick. Thandy: Secure Update for Tor. 2009. Reference found on “blogspot.com” Internet site at http://google-opensource.blogspot.com/2009/03/thandy-secure-update-for-tor.html” on November 4, 2010 and on February 13, 2012.

[37] Projects for Thandy. Reference found on “trac.torproject.org” Internet site at https://trac.torproject.org/projects/tor/wiki/projects/Thandy on November 4, 2010 and at https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Thandy on February 13, 2012.



http://crypto.stanford.edu/~nagendra/papers/dtls.pdf




http://seagull.sourceforge.net/

http://seagull.sourceforge.net/

http://gull.sourceforge.net

http://gull.sourceforge.net

http://www.hping.org/

http://www.hping.org/

http://nmap.org/

http://nmap.org/

http://nmap.org/ncat/

http://nmap.org/ncat/

http://trac.edgewall.org/

http://trac.edgewall.org/

https://www.torproject.org/

https://www.torproject.org/

http://www.mozilla.com/firefox/




http://www.mozilla.org/en-US/firefox/new/

http://www.mozilla.org/en-US/firefox/new/

http://www.gnu.org/software/wget/




http://www.wireshark.org/

http://www.wireshark.org/

http://consultants-online.co.za/pub/itap_101/html/ch05s06.html




http://google-opensource.blogspot.com/2009/03/thandy-secure-update-for-tor.html




https://trac.torproject.org/projects/tor/wiki/projects/Thandy




https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Thandy






[38] Samuel, Justin and Mathewson, Nick and Dingledine, Roger and Cappos, Justin. Survivable Key Compromise in Software Update Systems. Reference found on “freehaven.net” Internet site at http://www.freehaven.net/~arma/tuf-ccs2010.pdf on November 5, 2010 and on February 13, 2012.

[39] Thandy: Automatic updates for Tor bundles. Reference found on “torproject.org” Internet site at https://gitweb.torproject.org/thandy.git/blob_plain/HEAD:/specs/thandy-spec.txt on November 5, 2010 and on February 13, 2012.

[40] Apache Subversion: Enterprise-class centralized version control for the masses. Reference found on “apache.org” Internet site at http://subversion.apache.org/ on November 5, 2010 and on February 13, 2012.

[41] git: the fast version control system. Reference found on “git-scm.com” Internet site at http://git-scm.com/ on November 5, 2010 and on February 13, 2012.

[42] Bazaar. Reference found on “canonical.com” Internet site at http://bazaar.canonical.com/en/ on November 5, 2010 and on February 13, 2012.

[43] Google Project Hosting. Reference found on “google.com” Internet site at http://code.google.com/projecthosting/ on November 5, 2010 and on February 13, 2012.

[44] Qt Creator: Cross-Platform IDE. Reference found on “nokia.com” Internet site at http://qt.nokia.com/products/developer-tools/ on November 5, 2010 and on February 13, 2012.

[45] Eclipse. Reference found on “eclipse.org” Internet site at http://eclipse.org on November 5, 2010 and on February 13, 2012.

[46] NetBeans. Reference found on “netbeans.org” Internet site at http://netbeans.org on November 5, 2010 and on February 13, 2012.

[47] The EFF SSL Observatory. Reference found on “eff.org” Internet site https://www.eff.org/observatory on February 12, 2012.

[48] SSL And The Future of Authenticity. Reference found on “thoughtcrime.org” Internet site http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity/ on February 12, 2012.

[49] Why Perspectives? Reference found on “perspectives-project.org” Internet site http://perspectives-project.org on February 12, 2012.

[50] Convergence (Beta). Reference found on “convergence.io” Internet site http://convergence.io on February 12, 2012.



http://www.freehaven.net/~arma/tuf-ccs2010.pdf

http://www.freehaven.net/~arma/tuf-ccs2010.pdf

https://gitweb.torproject.org/thandy.git/blob_plain/HEAD:/specs/thandy-spec.txt

https://gitweb.torproject.org/thandy.git/blob_plain/HEAD:/specs/thandy-spec.txt

http://subversion.apache.org/

http://subversion.apache.org/

http://git-scm.com/

http://git-scm.com/

http://bazaar.canonical.com/en/

http://bazaar.canonical.com/en/

http://code.google.com/projecthosting/




http://qt.nokia.com/products/developer-tools/




http://eclipse.org

http://eclipse.org

http://netbeans.org

http://netbeans.org

https://www.eff.org/observatory




http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity/

http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity/

http://perspectives-project.org




http://convergence.io

http://convergence.io



[51] Flash Proxies. Reference found on “stanford.edu” Internet site http://crypto.stanford.edu/flashproxy/ on February 13, 2012.

[52] Datagram Transport Layer Security. Reference found on “ietf.org” Internet site http://tools.ietf.org/html/rfc4347 on February 13, 2012.

[53] DigiNotar Hacked by Black.Spook and Iranian Hackers. Reference found on “f-secure.com” Internet site http://www.f-secure.com/weblog/archives/00002228.html on February 13, 2012.

[54] What You Need to Know About the DigiNotar Hack. Reference found on “threatpost.com” Internet site http://threatpost.com/en_us/blogs/what-you-need-know-about-diginotar-hack-090211 on February 13, 2012.

[55] DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model. Reference found on “freedom-to-tinker.com” Internet site https://freedom-to-tinker.com/blog/sjs/diginotar-hack-highlights-critical-failures-our-ssl-web-security-model on February 13, 2012.

[56] GYB Proxy Project Code - v0.1 branch revision 1. Reference found on “launchpad.net” Internet site http://bazaar.launchpad.net/~wkenzie/gybproxy/v0.1/revision/1 on February 13, 2012.

[57] GYB Proxy Project Code - v0.1 branch revision 163. Reference found on “launchpad.net” Internet site http://bazaar.launchpad.net/~wkenzie/gybproxy/v0.1/revision/163 on February 13, 2012.

[58] Fast portable non-blocking network programming with Libevent. Reference found on “wangafu.net” Internet site http://www.wangafu.net/~nickm/libevent-book/TOC.html on February 13, 2012.

[59] Libevent - an event notification library. Reference found on “libevent.org” Internet site http://libevent.org/ on February 13, 2012.

[60] node.js. Reference found on “nodejs.org” Internet site http://nodejs.org/ on February 13, 2012.

[61] About node.js. Reference found on “nodejs.org” Internet site http://nodejs.org/about/ on February 13, 2012.

[62] The secrets of Node’s success. Reference found on “oreilly.com” Internet site http://radar.oreilly.com/2011/06/node-javascript-success.html on February 13, 2012.

[63] Proxyup Project Code - master branch revision 1. Reference found on “launchpad.net” Internet site http://bazaar.launchpad.net/~wkenzie/proxyup/master/revision/1 on February 13, 2012.



http://crypto.stanford.edu/flashproxy/




http://tools.ietf.org/html/rfc4347




http://www.f-secure.com/weblog/archives/00002228.html

http://www.f-secure.com/weblog/archives/00002228.html

http://threatpost.com/en_us/blogs/what-you-need-know-about-diginotar-hack-090211




https://freedom-to-tinker.com/blog/sjs/diginotar-hack-highlights-critical-failures-our-ssl-web-security-model




http://bazaar.launchpad.net/~wkenzie/gybproxy/v0.1/revision/1




http://www.wangafu.net/~nickm/libevent-book/TOC.html

http://www.wangafu.net/~nickm/libevent-book/TOC.html

http://libevent.org/

http://libevent.org/

http://nodejs.org/

http://nodejs.org/

http://nodejs.org/about/

http://nodejs.org/about/

http://radar.oreilly.com/2011/06/node-javascript-success.html




http://bazaar.launchpad.net/~wkenzie/proxyup/master/revision/1




[64] Proxyup Project Code - master branch revision 96. Reference found on “launchpad.net” Internet site http://bazaar.launchpad.net/~wkenzie/proxyup/master/revision/96 on February 13, 2012.

[65] V8 JavaScript Engine. Reference found on “code.google.com” Internet site http://code.google.com/p/v8/ on February 13, 2012.

[66] Node.js and MongoDB - Getting started with MongoJS. Reference found on “howtonode.org” Internet site http://howtonode.org/node-js-and-mongodb-getting-started-with-mongojs on February 13, 2012.

[67] Node.js Developer Center. Reference found on “windowsazure.com” Internet site http://www.windowsazure.com/en-us/develop/nodejs/ on February 13, 2012.

[68] Windows Azure SDK for Node.js. Reference found on “github.com” Internet site https://github.com/WindowsAzure/azure-sdk-for-node on February 13, 2012.

[69] Openness Update for Windows Azure. Reference found on “technet.com” Internet site http://blogs.technet.com/b/port25/archive/2011/12/11/openness-update-for-windows-azure.aspx on February 13, 2012.

[70] Announcing ql.io. Reference found on “ebaytechblog.com” Internet site http://www.ebaytechblog.com/2011/11/30/announcing-ql-io/ on February 13, 2012.

[71] Exclusive: How LinkedIn used Node.js and HTML5 to build a better, faster app. Reference found on “venturebeat.com” Internet site http://venturebeat.com/2011/08/16/linkedin-node/ on February 13, 2012.

[72] Multi-Core HTTP Server with NodeJS. Reference found on “developer.yahoo.com” Internet site http://developer.yahoo.com/blogs/ydn/posts/2010/07/multicore_http_server_with_nodejs/ on February 13, 2012.

[73] Node @ Facebook. Reference found on “broofa.com” Internet site http://broofa.com/presentations/FacebookAtNode_NodeConf2011.pdf on February 13, 2012.

[74] Node.js at Facebook - Why it’s Needed and What’s Holding it Back. Reference found on “readwriteweb.com” Internet site http://www.readwriteweb.com/cloud/2011/05/nodejs-at-facebook.php on February 13, 2012.

[75] Laurie, Ben and Langley, Adam. Certificate Authority Transparency and Auditability. Reference found on “links.org” Internet site http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf on February 14, 2012.

[76] von Leitner, Felix. Scalable Network Programming. Reference found on “fefe.de” Internet site http://bulk.fefe.de/scalable-networking.pdf on February 14, 2012.





http://code.google.com/p/v8/




http://howtonode.org/node-js-and-mongodb-getting-started-with-mongojs

http://howtonode.org/node-js-and-mongodb-getting-started-with-mongojs

http://www.windowsazure.com/en-us/develop/nodejs/




https://github.com/WindowsAzure/azure-sdk-for-node




http://blogs.technet.com/b/port25/archive/2011/12/11/openness-update-for-windows-azure.aspx




http://www.ebaytechblog.com/2011/11/30/announcing-ql-io/




http://venturebeat.com/2011/08/16/linkedin-node/

http://venturebeat.com/2011/08/16/linkedin-node/

http://developer.yahoo.com/blogs/ydn/posts/2010/07/multicore_http_server_with_nodejs/

http://developer.yahoo.com/blogs/ydn/posts/2010/07/multicore_http_server_with_nodejs/

http://broofa.com/presentations/FacebookAtNode_NodeConf2011.pdf




http://www.readwriteweb.com/cloud/2011/05/nodejs-at-facebook.php




http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf




http://bulk.fefe.de/scalable-networking.pdf

http://bulk.fefe.de/scalable-networking.pdf



[77] Auerbach, Dan and Eckersley, Peter. Researchers Use EFF’s SSL Observatory To Discover Widespread Cryptographic Vulnerabilities. Reference found on “eff.org” Internet site https://www.eff.org/deeplinks/2012/02/researchers-ssl-observatory-cryptographic-vulnerabilities on February 15, 2012.

[78] The Apache CouchDB Project. Reference found on “apache.org” Internet site http://couchdb.apache.org/ on February 15, 2012.

[79] Use Cases - MongoDB. Reference found on “mongodb.org” Internet site http://www.mongodb.org/display/DOCS/Use+Cases on February 15, 2012.

[80] Introduction to Redis. Reference found on “redis.io” Internet site http://redis.io/topics/introduction on February 15, 2012.

[81] OpenVPN - Open Source VPN. Reference found on “openvpn.net” Internet site http://openvpn.net/ on February 15, 2012.

[82] Obfsproxy: the next step in the censorship arms race. Reference found on “torproject.org” Internet site https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race on February 16, 2012.

[83] Node LICENSE. Reference found on “github.com” Internet site https://github.com/joyent/node/blob/master/LICENSE on February 16, 2012.

[84] The MIT License. Reference found on “www.opensource.org” Internet site http://www.opensource.org/licenses/mit-license.php on February 16, 2012.

[85] York, Dan. How to use Node.js with IPv6. Reference found on “danyork.com” Internet site http://code.danyork.com/2011/01/21/how-to-use-node-js-with-ipv6/ on February 16, 2012.

[86] Ellis, Jonathan. Cassandra: Fact vs fiction. Reference found on “blogspot.com” Internet site http://spyced.blogspot.com/2010/04/cassandra-fact-vs-fiction.html on February 16, 2012.

[87] syslog remote logging. Reference found on “google.com” Internet site https://www.google.com/?q=syslog+remote+logging on February 16, 2012.

[88] SOCKS4. Reference found on “wikipedia.org” Internet site http://en.wikipedia.org/wiki/SOCKS#SOCKS4a on February 16, 2012.

[89] SOCKS Protocol Version 5. Reference found on “ietf.org” Internet site http://tools.ietf.org/html/rfc1928 on February 16, 2012.



https://www.eff.org/deeplinks/2012/02/researchers-ssl-observatory-cryptographic-vulnerabilities




http://couchdb.apache.org/




http://www.mongodb.org/display/DOCS/Use+Cases




http://redis.io/topics/introduction




http://openvpn.net/

http://openvpn.net/

http://openvpn.net/

http://openvpn.net/

https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race

https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race

https://github.com/joyent/node/blob/master/LICENSE




http://www.opensource.org/licenses/mit-license.php




http://code.danyork.com/2011/01/21/how-to-use-node-js-with-ipv6/

http://code.danyork.com/2011/01/21/how-to-use-node-js-with-ipv6/

http://spyced.blogspot.com/2010/04/cassandra-fact-vs-fiction.html

http://spyced.blogspot.com/2010/04/cassandra-fact-vs-fiction.html

https://www.google.com/?q=syslog+remote+logging




http://en.wikipedia.org/wiki/SOCKS#SOCKS4a










[90] Perham, Mike. Node.js, Part II: Spelunking in the Code. Reference found on “carbonfive.com” Internet site http://blog.carbonfive.com/2011/03/14/node-js-part-ii-spelunking-in-the-code/ on February 16, 2012.

[91] Lehmann, Marc. libev. Reference found on “schmorp.de” Internet site http://software.schmorp.de/pkg/libev.html on February 16, 2012.

[92] c-ares. Reference found on “haxx.se” Internet site http://c-ares.haxx.se/ on February 16, 2012.

[93] Node.js dns. Reference found on “nodejs.org” Internet site http://nodejs.org/docs/latest/api/dns.html on February 16, 2012.

[94] Node.js secure pair object. Reference found on “nodejs.org” Internet site http://nodejs.org/docs/latest/api/all.html#pair_tls.createSecurePair on February 17, 2012.

[95] Node.js stream.pipe() function. Reference found on “nodejs.org” Internet site http://nodejs.org/docs/latest/api/all.html#stream.pipe on February 17, 2012.

[96] Canonical and Ubuntu. Reference found on “ubuntu.com” Internet site http://www.ubuntu.com/project/canonical-and-ubuntu on May 8, 2012.



http://blog.carbonfive.com/2011/03/14/node-js-part-ii-spelunking-in-the-code/

http://blog.carbonfive.com/2011/03/14/node-js-part-ii-spelunking-in-the-code/

http://software.schmorp.de/pkg/libev.html




http://c-ares.haxx.se/

http://c-ares.haxx.se/

http://nodejs.org/docs/latest/api/dns.html




http://nodejs.org/docs/latest/api/all.html#pair_tls.createSecurePair




http://nodejs.org/docs/latest/api/all.html#stream.pipe




http://www.ubuntu.com/project/canonical-and-ubuntu






4(b). DVD Contents

The DVD accompanying this Report consists of the following directories and files:

COMP8045_Practicum_Final_Updated.pages (this report in Apple Pages format)COMP8045_Practicum_Final_Updated.pdf (this report in Adobe PDF format)COMP8045_Practicum_Final_Updated.doc (this report in Microsoft Word format)COMP8045_Practicum_Title_Updated.pages (this report title page in Apple Pages format)COMP8045_Practicum_Title_Updated.pdf (this report title page in Adobe PDF format)COMP8045_Practicum_Title_Updated.doc (this report title page in Microsoft Word format)

proxyup (working directory for starting up Proxyup app)

bin (Proxyup startup script) docs (placeholder directory for Proxyup documentation)

keys (self-generated certificates, keys and logs)

lib (Proxyup functions and scripts)

manhandlers (Proxyup middleware setup functions)

middleware (Proxyup middleware functions)

node_modules (node module dependencies)

testing (test result log files and pcap files)

tlsman (TLS Middleware Console HTML, CSS, JS files)

utils (JavaScript utility functions)

COPYRIGHT (copyright notice) LICENSE (license terms) LICENSE-middlefiddle (license terms of middlefiddle project) package.json (node package information) proxy.pac (sample, tentative proxy auto-config) proxyup_cert_request.csr (self-generated certificate request) proxyup_cert.pem (self-generated certificate for TLS middleware console) proxyup_private_key.pem (self-generated private key) README.md (readme in “markdown” format)





BCIT COMP 8045 Practicum Report by Wesley Kenzie, May 2012

Documents

Transcript of BCIT COMP 8045 Practicum Report by Wesley Kenzie, May 2012