SSL: Signed Certificate

SSL - Signed Certificate

 

The certificate is identical to the certificate request with the addition of the certificate authority’s signature.  The is composed of the endpoint’s distinguished name,  public key and signature. The distinguished name contains details about the certificate bearer including country, state or province, locality, details about the entity the certificate represents, and often an email to contact if there are problems. The public key is needed later to allow the SSL handshake to be performed securely. The signature is generated by digesting the entire certificate and encrypting the digest with the certificate authority’s public key.  The signature ensures the certificate has not been modified since signing and that it was actually signed by the certificate authority.  Thus, certificates provide a measure of trust when signed by a legitimate certificate authority.

 

SSL: Certificate Request

SSL - Certificate RequestThe certificate request is composed of the endpoint’s distinguished name and public key. The distinguished name contains details about the certificate bearer including country, state or province, locality, details about the entity the certificate represents, and often an email to contact if there are problems. The public key is needed later in the signed certificate to allow the SSL handshake to be performed securely.

 

SSL – Certificate Authority

SSL - Certificate AuthorityCertificate subject (client or server) sends a certificate request to the certificate authority to get a certificate issued. The certificate authority thoroughly verifies information included in the certificate request.  Once the certificate authority has done it’s due diligence it will digest and sign the the certificate request with the certificate authority’s private key to create a signed certificate.  Finally, the certificate authority issues the signed certificate to the certificate subject.  Any machine or organization may be a certificate authority and issue certificates.  Every machine has a collection of trusted certificates, these trusted certificates allow the machine to trust any and every machine issued a certificate by the certificate authority that owns the trusted certificate.  Trusting a certificate should be done with great care – trusting a bad certificate authority can completely undermine the security of your system and network.  Some well-known and widely trusted certificate authorities include Verisign and DigiCert. In summary, getting a certificate issued is much like getting a driver’s license: You fill out the certificate request (application) with relevant information, the certificate authority (DMV) verifies your identity and issues a signed certificate (driver’s license) that proves your identity to others and is extremely difficult to counterfeit perfectly.

SSL – Overview

SSL - Secure Communication

The Secure Socket Layer (SSL), also known as Transport Layer Security (TLS), is one of the fundamental technologies supporting the web today.  SSL/TLS provides the security needed to keep information confidential that crosses the Internet, verify the identity of the other machine, and ensure the that information isn’t tampered in transit through the world wide web.  The first step in the process is for every server to get a certificate from a reputable certificate authority that  proves it’s identity.  Clients may also be issued identifying certificates to ensure two-way identification.  When two devices want to communicate, they perform an exchange of information (handshake) that helps establish their identities and set up a secured connection. To establish trust, they send their certificates to one another and by using the trusted certificate authority’s own certificate the can verify the identity of the other machine.  Clients are not normally required to provide a certificate, however servers must provide a certificate.  Once the handshake is complete and they trust each other, they may begin communicating data  between them without fear of eavesdropping or tampering.

REST – Universal Identifier

Finally, REST architecture relies on resource identifiers that are: unique, unambiguous, universal across the system and universally accessible regardless of context. Put more simply, identifiers should provide a way to access a resource from anywhere in a consistent fashion as long as the resource is available.

These identifiers are typically URIs, URLs, and URNs. URIs (Uniform Resource Identifiers) can be classified as locators (URLs [Uniform Resource Locators]), as names (URNs [Uniform Resource Names]), or as both. A URN functions like the scientific names given to plants, animals, and compounds. A URL provides an address like those used to identify homes, businesses and websites. Stated concisely: the URN defines an item’s unique identity, while the URL provides a method for finding it.

Note that REST does not require the identifier to be human readable. The ASN.1 OID 1.3.6.1 is as valid as the latin name Candida Albicans for describing a unique object or resource. However, since systems are built, used and maintained primarily by people, many RESTful systems devote a significant amount of time to crafting readable resource identifiers.  For example, Instagram uses a hierarchy in crafting readable URLs for their API. Retrieving the photos you have liked is accomplished by calling  users/self/media/liked using Instagram’s public API. In short: resources should be easily and uniquely referenced via resource identifier’s that may or may not be easy to decipher.

REST – Mapping Behavior to Implementation

A key concept in a REST architecture is a mapping between behaviors and the implementation. The best known way to this is mapping HTTP methods to resource behaviors.  The applicable HTTP methods are GET, PUT, POST, DELETE, and HEAD.  I will not be discussing the TRACE and CONNECT methods in this post.  GET, PUT and HEAD are idempotent methods, meaning the result of the method (state of the resource) will be the same regardless of when, where or how many times they are called on a particular resource.  Idempotency allows among other things the caching of responses, increasing the efficiency of the application or system.

GET is the HTTP method we are most familiar with, it is essentially the surfboard used to surf the web.  GET returns the representation of the resource requested.  In the case of the web, GET returns HTML pages, CSS style sheets, JavaScript scripts and variety of media (sounds, music, pictures, video, etc . . .).

PUT sends an entire resource representation to the server or peer to create or update a resource.  The resource representation must be sent in it’s entirety because the resource cannot be updated in parts or portions because of PUT’s idempotency.

POST is the second most popular HTTP method, POST is used frequently in AJAX calls, form submissions and anything else imaginable.  POST is a processing directive for the resource referred to in the URI/URL to handle, as such, the server or peer may handle the POST in any they define.  POST is often used to update a resource, create a resource, call another HTTP method that’s not supported by the client or trigger some other processing on the server/client.

HEAD is identical to GET except it does not return the resource, rather it returns the existence and size of the resource that would be returned by a GET request.

DELETE requests the deletion of the resource found at the URI/URL address.

The idempotency and cacheability of GET, HEAD, and PUT allow for robust, efficient, and scaleable systems.  The immense power and flexibility POST allow enumerable systems and applications in every domain to live on the internet.

REST – Resource Representation

At it’s heart REST, hypermedia and therefore HATEOS revolve around linking and managing resources.  Resources like nouns represent persons, places, things, concepts,  states, or qualities.  A resource is an available asset, representation of real-world entities, or a source of supply, support, or aid.  Though REST does not define what resource representations should look like, they should be easy to understand, parse and manipulate.

JavaScript Object Notation (JSON) is one popular format for data representation and transmission.  JSON is a simple and flexible system that compactly represents data as name-value pairs.  JSON is widely known for it’s readability, ease of use and ubiquity. JSON is most often found as the way JavaScript stores data in web applications.

Extensible Markup Language (XML) is another extremely common way to represent data.  XML is quite powerful because it allows for the creation of sophisticated structures in the data representation.  XML is crafted with a combination of open, closing and self-closing tags, tag attributes and of course the contents of the tags.   XML is readable, quite verbose (reducing it’s compactness), and like JSON is both easy to use and ubiquitous. The Extensible Hypertext Markup Language (XHTML) is the Hypertext Markup Language (HTML) that conforms to the conventions and guidelines of well-form XML in order to enjoy XML’s advantages.

Although the resource representation chosen is not significant to REST, there MUST be a resource representation to transfer state between clients, servers, and peers in an architecture built on REST.  Resource representations should be well thought out, consistent, easy to modify and most importantly tailored to the problem they are used to solve.

REST – HATEOAS

HATEOAS (Hypermedia As The Engine Of Application State)

Links between resources drive the state of peers, clients and servers. These hyperlinks provide transitions between the states of a given resource. Each resource representation has at least one link to another resource, thus creating hypermedia. Clients learn the state of a resource and it’s relationship to other resources through it’s resource representation.   This is the principle that enables HTTP and HTML to weave the World Wide Web.  A browsers points to a web page (resource),  the server responds with the page, the browser then reads the page and requests all the images, scripts, style sheets, and pages referenced in frames and iframes (resources).  Finally, the browser renders the page using each resource where it’s needed.  The rendered page often contains numerous links to other pages or files (resources). This structure allows people to surf the web on the waves of hypermedia.

REST – Representational State Transfer

In 2000, Roy Thomas Fielding published his Doctorate Dissertation: Architectural Styles and the Design of Network-based Software Architectures.  Doctor Fielding introduced a number of ideas critical to the growth and evolution of the web.  The heart of these ideas is REST. In recent years, REST and RESTful web services have enjoyed great success and popularity.  Doctor Fielding said it best in the following citation:

“Representational State Transfer (REST) architectural style for distributed hypermedia systems, as it has been developed to represent the model for how the modern Web should work. REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.”

Contrary to popular belief, REST is NOT simply a means to implement Remote Procedure Calls (RPC) through a well crafted URL.  REST is primarily concerned with managing, retrieving and linking resources in such a way that it may effectively scale without bound.

Concisely stated, REST is an architectural style built on the following four ideas:

  • HATEOAS (Hypermedia As The Engine Of Application State)
  • Resources representing people, places, things, and other nouns
  • Global identifiers to access resources
  • A mapping between application behaviors and the application code

CSS – Reveal Element Ancestry

Oftentimes, I find it difficult to conceptualize the exact ancestry of an element in a complicated page. I wrote these styling rules to dynamically reveal the structure of a page as I view it. The style reveals the structure of the document immediately below the cursor making each nesting obvious.  When the cursor hovers over an element, it and each of its parents are given a border, aesthetic padding and rounding  and slight zooming  to make the element’s nested structure pop out. This is a dynamic change that occurs real-time as the cursor moves across the page.  Due to restrictions on blog content, the renderings at the end of this post are static.

HTML

< div class=”TierOne”>

<div class=”TierTwo”>

<div class=”TierThree A”>

A

</div

<div class=”TierThree B”>

B

</div>

</div>

</div>

CSS

*:hover

{

border: 5px black solid;

border-radius: 10px;

margin: 5px;

padding: 5px;

zoom: 1.1;

}
Result
Mouse not on page

A
B

Mouse over Tier One

A
B

Mouse over Tier Two

A
B

Mouse over Tier Three A

A
B

Mouse over TierThree B

A
B