Skip navigation
All Places > Web Performance > Blog
1 2 3 Previous Next

Web Performance

258 posts

Akamai is a leader in the CDN and security spaces. However, it is a true powerhouse in ensuring its Service Level Agreements (SLAs) through leading Professional Services. In order to harness this power, every Akamai service request needs sufficient requirements.

 

Here, we have declassified, demystified and defined what makes good requirements. In one word, it is explicitness.

 

The Requirements Cookbook

  1. Always provide test URLs: this alone will dramatically increase the speed of your service request
    • [At least] one for a positive test
    • One for a negative test
  2. State the end goal, not the problem: fight the disease, not the symptom
    • It's almost always faster to solve for the end goal
    • Trying to limit the solution to the symptom effectively limits Akamai's options
  3. Now state the problem: ideally break it down into a pipeline of dependent problems
    • Provide unit tests for each stage of the problem
  4. Use Akamai service hours: here is where I need to be blunt
    • DON'T BE CHEAP! Akamai provides service hours for a reason, please use them
    • At the very least, create an Akamai support ticket and put the requirements there
  5. Save hours by troubleshooting: This is the correct way to save time/money
  6. Try DIY for an hour: first try to fix the problem yourself

 

Please feel free to make an Akamai support ticket if you ever need help with requirements. Be explicit, try to follow the above recipe and be generous with your test URLs. Thanks for reading!

Check out the latest blog post from Ted Shuter, Akamai Ion Sr Product Manager, around Script Management, a new Ion feature that helps manage the impact of scripts and protect from unresponsive 3rd parties.

This blog post has been updated since it was originally published on August 29, 2017. Changed items are marked with "New" or "Updated". An update history is available at the end of this page.

 

Background on the Google/Symantec SubCA Transition

At the beginning of 2017, the Google Chrome team started investigating Symantec for mis-issuing certain TLS server certificates. Over the last five months, Google and Symantec have been working to restore the industry’s confidence in certificates issued by Symantec, including certificates under the GeoTrust, RapidSSL, and Thawte brands. As always, Akamai is in close contact with Symantec, our certificate partner, providing feedback on the proposals, and representing our customers’ interests.

 

Google and Symantec have now indicated that trust for certificates issued by Symantec from their existing PKI infrastructure will be phased out by the Google Chrome browser in two phases, April 2018 and October 2018. After these dates, Google Chrome (and other browsers that follow suit) will stop showing the “secure padlock” for sites presenting these certificates. They may even show “insecure site” warnings in the address bar or on error pages. All existing Symantec certificates need to be renewed on their new PKI infrastructure (available December 1, 2017) to continue to be trusted in future versions of Google Chrome.

 

Akamai is committed to making this transition smooth for our customers. Most of the affected customer certificates will rotate automatically, before Chrome’s scheduled actions. In these cases, there is no action customers need to take. Some Akamai-managed customer certificates and some third-party (customer-managed) certificates will need to be rotated early. For these certificates, Akamai will shift the scheduled renewal start date to be several months before the Chrome distrust dates. This will give time for those certificates to be rotated before the scheduled distrust dates. In all cases, customers can choose to rotate their certificates early through our Certificate Provisioning System (CPS) in the Luna portal. See below for more details.

 

Affected Certificates

The upcoming changes, affect all certificates issued by Symantec. For Akamai customers, this includes:

  • All Akamai-managed Symantec OV Single, SAN, Wildcard, and Wildcard SAN certificates,
  • All Akamai-managed GeoTrust OV Single, SAN, and Wildcard certificates,
  • All Akamai-managed Symantec EV Single and SAN certificates, and
  • Some customer-managed third-party certificates.

 

Akamai-managed certificates issued by Comodo and Let’s Encrypt are not affected by these changes.

 

Distrust Schedule

Chrome 66 (beta in March 2018, stable April 2018) will no longer trust Symantec-issued certificates with a Not Before date of June 1, 2016 or prior.

  • No currently-valid Akamai-managed Symantec- or GeoTrust-branded OV certificates are affected by this phase out. All current Akamai-managed OV certificates were issued after June 1, 2016.
  • No currently-valid Akamai-managed Symantec-branded EV certificates are affected by this phase out. All current Akamai-managed EV certificates were issued after June 1, 2016.

 

Chrome 70 (beta in September 2018, stable October 2018) will no longer trust any Symantec-issued certificates issued prior to December 1, 2017, or from their old PKI infrastructure.

  • All Akamai-managed Symantec- and GeoTrust-branded OV certificates ordered before December 1, 2017 are affected by this phase out.
  • All Akamai-managed Symantec-branded EV certificates ordered before December 1, 2017 are affected by this phase out.

 

Google and Symantec have indicated that certificates ordered and issued by Symantec and GeoTrust after December 1, 2017 will be trusted in all planned future versions of Chrome.

 

New Trust Chains Updated

Google and Symantec have indicated that all certificates ordered and issued after December 1, 2017 will be issued on a new PKI platform. New certificates will be issued with different trust chains (intermediate and root certificates) from those obtained today. Most customers will not notice this change as certificates issued with the new trust chains will continue to be trusted by existing browsers. OV certificates issued under the GeoTrust and Symantec brands (both RSA and ECDSA) will chain to the “DigiCert Global Root CA”. EV certificates issued by Symantec (both RSA and ECDSA) will chain to the “DigiCert High Assurance EV Root CA”. Both of these root certificates have a high level of ubiquity and inclusion in web browsers’ and operating systems’ trust stores. Most clients that could connect to properties secured with certificates chaining to the old “VeriSign Class 3 Public Primary Certification Authority - G5” root will be able to connect to the same properties once their certificates are rotated onto the new trust chains.

 

Akamai publishes a list of SSL/TLS certificate chains for Akamai-managed certificates. This list has been updated with the new trust chains for Akamai-managed GeoTrust and Symantec certificates ordered and issued after December 1, 2017.

 

With these new trust chains from Symantec, Akamai is no longer able to offer managed certificates chaining up to the “VeriSign Class 3 Public Primary Certification Authority - G5” root (also known as the “G5” root), or the legacy “Class 3 Public Primary Certification Authority” root (also known as a “1k root”). We recommend that customers move away from the 1k root as soon as possible. Most customers have no need for the 1k root as TLS clients have been upgraded to support the Default trust chain. This can be accomplished today in our Certificate Provisioning System (CPS) by selecting the “Default” trust chain for your certificates.

 

What actions do customers need to take?

  • If your certificates were issued prior to June 1, 2016, they will need to be renewed prior to April 2018. We will reach directly to the affected customers and will start early renewal of these certificates in January 2018.
  • All currently-valid Akamai-managed OV certificates issued prior to October 2017 will automatically rotate on their regular schedule 60 days prior to expiration. This means that existing and future certificates, issued prior to October 2017, will all naturally expire prior to being distrusted in October 2018. Existing certificates will continue to be trusted by browsers until they are replaced with the newly issued certificates. No customer actions beyond responding to the validation emails and phone calls from Symantec are required.
  • All other Akamai-managed OV certificates issued between October 2017 and December 2017, as well as all Akamai-managed EV certificates, regardless of issuance date, will need to be renewed prior to October 2018. Starting in January 2018, we will be in touch with the affected customers. We intend to shift the renewal dates earlier for existing certificates so their replacements can be issued prior to the October 2018 distrust date.
  • The scheduled distrust of Symantec-issued certificates applies to all Symantec brands including GeoTrust, RapidSSL, and Thawte. Customers who have third-party certificates on the Akamai Secure CDN from these brands may also be affected by these changes. These third-party certificates can be renewed after December 1, 2017 by generating and downloading a CSR from our Certificate Provisioning System (CPS), and sending that CSR to Symantec to obtain a new certificate.
  • At any time, customers can force early renewal of their certificates (both Akamai-managed and third-party) by going into CPS (Legacy) and performing an “Edit and Submit” action for your certificate. We recommend waiting until after December 1, 2017 when certificates will be issued by Symantec’s new PKI infrastructure. This functionality will be available in an upcoming release of the current version of CPS.

 

FAQ

Is there a cost or contract impact because of this change?

No, your current contracted rates remain intact. No additional Akamai paperwork is required.

 

Why is Akamai continuing to partner with Symantec for certificate issuance?

Symantec, and soon to be DigiCert, is the global leader in SSL/TLS certificate issuance. They continue to be the best fit for the needs of our customer base. As announced in April 2016, Symantec remains our strategic partner for issuance of OV and EV certificates.

 

What if I do not want an OV or EV certificate from Symantec?

Akamai offers fully managed and automated DV SAN certificates from Let’s Encrypt. We also offer a third-party solution that gives customers the ability to get an SSL certificate of any type from their provider of choice.

 

How will the sale of Symantec’s PKI business to DigiCert affect my certificates? Updated

DigiCert’s parent company, Thoma Bravo, acquired the Symantec PKI business in October 2017 (Symantec’s fiscal Q3 2018). Under current plans, this purchase does not impact the transition process outlined above. Even after the sale, customers with Akamai-managed OV and EV certificates will continue to use the same provisioning process as they do today, using CPS in our Luna portal. Google and Symantec have indicated that certificates ordered and issued after December 1, 2017 on the new Symantec infrastructure will continue to be trusted until their expiration date. Newly issued certificates will chain up to an existing DigiCert root.

 

Which browsers besides Google Chrome will also distrust certificates? New

Mozilla has indicated that Firefox will follow a similar schedule to distrust certificates as published by Google for Chrome. Even if your secure property does not target Google Chrome users, we recommend rotating your certificates before the planned distrust dates.

 

The Javascript Console in the Google Chrome Web Inspector is displaying a warning about the certificate on my site. What should I do? New

Most customer certificates will expire and be renewed prior to the scheduled distrust date. The newly issued certificates will not be subject to the Chrome distrust, and will be usable until they expiry date. For these certificates, the browser warning can be safely ignored. For those certificates which expire after September 2018, Akamai will shift the scheduled renewal start date to be several months before the Chrome distrust dates. This will give time for those certificates to be rotated before the scheduled distrust dates.

 

My applications are sensitive to trust chain changes. What should I do?

Ensure that Change Management (“Test on Staging”) is turned on for your certificates in our Certificate Provisioning System (CPS). This feature will allow you to inspect and test new certificates in Staging prior to production deployment. Akamai strongly discourages customers from pinning certificates in their applications.

 

Can you provide the new trust chains before my certificate is rotated?

The new trust chains, including intermediate certificates and roots are available in our Community at SSL/TLS certificate chains for Akamai-managed certificates.

 

My applications require the existing “PCA-G5” root (“C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5”). How can I continue to use this root on my secure properties? New

We recommend that customers move away from the “G5” root and related trust chains. Symantec is no longer issuing certificates chaining to this root through partners, but may continue to do so for their direct customers. Akamai is unable to offer certificates with this root on managed certificates after December 1, 2017. If customers obtain these certificates directly from Symantec, Akamai will support them via the third-party certificate process. Please reach to your account team for details.

 

What if my applications require a 1k root like the one provided by the “C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority” root? Updated

We recommend that customers move away from the 1k root as soon as possible. Symantec no longer officially supports a 1k root option, and therefore Akamai is unable to offer this option on managed certificates after December 1, 2017. If your web property still needs a 1k root certificate, please reach to your account team to discuss how you can continue using a 1k root certificate through our third-party certificate process.

 

What happens if my certificate has the “Cross-signed 1k root” option enabled in CPS? New

The “Cross-signed 1k root” is a legacy option enabling an SSL/TLS certificate with a cross-signed certificate chain up to a 1k root. These certificates support legacy devices or platforms with older trust stores, or trust stores that cannot be updated. The 1k root option is no longer supported by our certificate authority. Certificates with this option enabled will receive the default trust chain on their next certificate modification.

 

How does this change affect OCSP Stapling? New

OCSP Stapling allows Akamai to obtain certificate validity and revocation data from a certificate authority, and then embed that information in the TLS connection between clients and Akamai servers. This feature saves browsers and clients from having to make their own connection to the certificate authority’s OCSP servers, and results in faster connection setup times. Akamai will continue to support OCSP Stapling on managed certificates. There may be a disruption in support for stapling for several weeks after December 1, 2017. All other operations will continue normally, and certificates can still be used to pass secure traffic. We intend to re-enable support for OCSP Stapling for Symantec certificates as soon as possible with no actions or changes needed by customers.

 

Can I obtain a new Symantec certificate prior to December 2017?

Customers can reissue certificates at any time by going into CPS (Legacy) and performing an “edit and submit” action for your certificate. We recommend waiting until after December 1, 2017 when certificates will be issued by Symantec’s new PKI infrastructure.

 

Why is Akamai waiting for most certificates to expire and be replaced, instead of forcing early renewal after December 2017?

While we could initiate early renewals of all our customers’ Symantec certificates, we manage tens of thousands of certificates on our Secure CDN. It is better for everyone, including our customers, if the renewal dates for certificates are spread out throughout the year.

 

My certificate had a renewal or a SAN modification order in process on December 1, 2017. How will this affect my certificate? New

Any order submitted to Symantec prior to the December 1, 2017 cutover to the new PKI hierarchy will be validated and issued by Symantec on the old PKI hierarchy. These certificates will need to be renewed prior to September 2017 in order to continue to be trusted in browsers. Akamai will shift the scheduled auto-renewal start date to be several months before the distrust dates to give time for those certificates to be rotated before the scheduled distrust dates.

 

When my certificate request is submitted to Symantec after December 1, 2017, will I have to go through the OV or EV validation process again? Updated

The exact validation steps at the time of certificate renewal will be determined by Symantec following the industry-standard CA/Browser Forum guidelines. Symantec and Google have indicated that validation data from Symantec’s old PKI infrastructure (for orders placed prior to December 1) cannot be reused.

 

I’m an existing GeoTrust customer. What happens to my GeoTrust certificate? Updated

Customers with GeoTrust certificates, a Symantec brand, issued through Akamai will continue to be renewed on GeoTrust. All GeoTrust certificates issued prior to December 2017 will have to be replaced by October 2018 to continue to be trusted in the Chrome browser. GeoTrust certificates ordered and issued after December 1, 2017 will be issued on a new trust chain and root certificate. Newly issued GeoTrust certificates will be trusted until they expire.

 

My applications require the “GeoTrust Global CA” root certificate. How do I obtain a certificate chaining up to this root? New

Akamai is unable to offer managed certificates chaining to the “GeoTrust Global CA” root certificate after December 1, 2017. Customers who need this root certificate should contact GeoTrust directly, and may upload them through our third-party certificate option. Please reach to your account team for details.

 

Can I convert my GeoTrust certificate to a Symantec SSL certificate?

Contact your account team to transition to the new certificate authority.

 

Is my DV SAN certificate from Let’s Encrypt impacted by this change?

Let’s Encrypt certificates are not impacted by these changes.

 

I still have an Akamai-managed EV certificate from Comodo. Is it impacted by this change?

Akamai-managed Comodo EV certificates are not impacted by these changes. As previously announced, existing Comodo certificates will be replaced with a Symantec certificate prior to current certificate expiration. If this scheduled renewal occurs prior to December 1, 2017, the resulting Symantec certificate will need to be renewed prior to October 2018.

 

Is my third-party certificate impacted by this change?

Customers who have third-party certificates on the Akamai Secure CDN from GeoTrust, RapidSSL, Symantec, and Thawte may be affected. Customers can replace these third-party certificates after December 1, 2017 by generating and downloading a CSR from our Certificate Provisioning System (CPS), and sending that CSR to Symantec to obtain a new certificate.

 

Is the trust chain of the Akamai shared certificate changing?

The trust chain of the “a248” shared certificates used for the a248.e.akamai.net, *.akamaihd.net, *.akamaihd-staging.net, *.akamaized.net, and *.akamaized-staging.net hostnames will change in line with the directions from Google and Symantec. We will post the new certificates on our Community page SSL/TLS certificate chains for the Akamai shared certificate when they are available.

 

My origin server has a certificate issued by Symantec. When will Akamai distrust this certificate?

Akamai will continue to trust Symantec certificates for connections from the Akamai Secure CDN to origin servers until those certificates expire.

 

 

If you any additional questions about this transition, please reach out to your Account Team or Akamai Technical Support.

 

 

 

Update December 12, 2017:

Added information on new trust chains, phase out of the “G5” and “1k” roots, DigiCert’s purchase of Symantec’s PKI business, Mozilla’s plans, and OCSP Stapling.

A new UI, an updated API, retiring Enhanced DNS and SOAP, and calling all REST API Developers!

 

Please see the following blog Big Changes Coming to Fast DNS in 2018 in the Cloud Security Fast DNS place.

Prateek Waghre

ICP Framework Updates

Posted by Prateek Waghre Employee Dec 4, 2017

Background

In 2005, MIIT issued regulations for Non Commercial Internet Content/Information Provider and stated that any internet content/information provider was not allowed to provide internet content service without a valid ICP Beian filed in the MIIT’s ICP system. Since then, the ICP Beian has been a mandatory requirement for all ChinaCDN customers.

With the internet industry and CDNs being relatively new to China at the time, to foster industry growth, the authorities did not strictly enforce the local hosting requirement during the ICP Beian process and with consent from the local authorities, ChinaCDN was able to provide this solution to all ChinaCDN global customers.

 

From 2016 onwards, a series of enforcement notices (see links 1, 2 and 3 below) have collectively stated that organizations who intend to serve their websites to end users in China must do so from servers located within China, and are required to setup hosting under the domain with a China based ISP.

So, what is happening now?

In July 2017, the MIIT further clarified that CDN services are strictly prohibited without a valid ICP (see link 3 below). As such, the government has signaled their intention to more strictly regulate how it issues and enforces the use of ICP Beian. Akamai and its partners in China agree that these requirements will affect customers with existing ICP Beian as well as those looking to procure new ICP Beian.

 

Due to this stricter enforcement of the ICP registration rules by MIIT, customers will need to host some content, with a licensed hosting service provider in China.

What does this mean for new and existing ICP registrations?

Any new ICP Beian applications will require some content to be hosted in China. There is some level of ambiguity concerning specifics of how much content needs to be hosted in China. The requirement can vary based on local regulation in different provinces/regions as well as the interpretation of rules by the ISP facilitating the procurement of the ICP Beian (ICP sponsor). Some ISPs have been known to ask for the www domain to be hosted in mainland China.

 

If you do not have a preferred hosting provider in China, Akamai can facilitate discussions with its partners.  

 

Existing ICP records also need to be updated to include local hosting provider information, if they do not have it already. Customers who procured their ICP Beian registration via Akamai’s partner relationship, and were affected, have already been notified.

For any questions/concerns, please contact your Akamai account team. Your account team’s contact information can be obtained from Luna Control Center (Support > Contact Support > Akamai Team for …). If you do not see this option in Luna Control Center, please reach out to your Point of Contact at the Akamai partner through with Akamai services have been procured and request them to put you in touch with your Akamai team.

 

For an ICP Beian registration that was procured via another service provider, it is recommended to contact the ICP sponsor to determine if any action is required.

 

Links (in Chinese)

  1. http://www.beian123.org.cn/news.php?id=1383
  2. http://www.miit.gov.cn/n1146295/n1652858/n1652930/n3757020/c5402051/content.html
  3. http://www.miit.gov.cn/n1146285/n1146352/n3054355/n3057709/n3057714/c5717035/content.html

Today's post was contributed by Akamai's very own Raphael Edwards

---------------------------------------------------------------------------------

Hello World. If you have a background in programming Hello World is something near and dear to you. It’s used to illustrate that the basic syntax of a programming language is working as intended. In the software world, it’s the moment where you turn the key for the first time, and hope the engine starts. These Hello World moments are happening at an increasing rate on today’s Internet. As the promise of the Internet of Things comes to fruition, everything from toothbrushes to salt shakers are getting online to make a Hello World introduction. By the end of 2017, Gartner forecasts ~8.3 Billion IoT connected devices, and by 2020 that number is expected to reach north of 20 Billion connected devices[1].  Notably, many of these devices were never designed to deal with today’s cyber-security threats or performance challenges in a mobile-first connected world.

 

In this article, we’re going to spotlight the automotive segment of IoT and connected vehicles to understand the challenges in delivering software updates or firmware over-the-air (FOTA). While automotive centric, you’ll find many of the challenges of mobile/cellular network delivery, cyber-security threats, visibility and reporting may be applied to other IoT growth verticals such as healthcare, retail, infrastructure, utilities/energy, financial services and more.

The connected vehicle market is poised to explode with close to 100 million connected vehicles expected to be on the road by 2020[2]. However, in today’s 2017 math, connected vehicles still only account for less than 5% of the total number of vehicles on the road.  We are truly at the cusp of a transportation transformation and the architectural, governance, and regulatory decisions made today couldn’t be more important.

 

As the connected vehicle market grows the vehicle threat landscape will continue to be an increased area of focus. The possibility of vehicle takeover[3] through compromised Internet connected vehicle components, elevation of privilege via owner services, or physical security is top of mind for every OEM and IoT manufacturer. The impact to the manufacturer and brand reputation is paramount. These risks are profound and each manufacturer must have a mitigation and recall strategy for vehicle defects. Historically, traditional recall campaigns of components and hardware have had the following challenges outlined below.

 

 

  • 20-30% of identified defect/recall campaigns are never completed by the consumer.[4]
  • Identification and diagnosis of issues requires the consumer to schedule a dealer service visit.
  • A percentage of consumers may not have close accessibility to a dealership network and may forgo a service visit, despite safety risks.
  • Consumer perception of defect severity and willingness to complete/schedule service visit.
  • Potentially a long time frame between defect identification, consumer communication, and service visit.
  • Lastly, effectiveness of recall communication campaign and accuracy of consumer contact information.

 

Each of the above challenges in traditional vehicle recall campaigns now presents an opportunity to drive brand differentiation and value added services. However, addressing each of these issues presents a unique technological, operational, and business challenge.

 

Presented below you’ll find the current challenges manufacturers are facing with the current state of IoT delivery.

 

THE IoT DELIVERY CHALLENGE

 

  • Performance and reliability at scale  For many manufacturers the overall deployment reach will target millions of connected vehicles. Ensuring firmware downloads / service updates are delivered reliably at scale will be a core differentiator in allowing manufacturers to respond to recall campaigns and drive value added services.
  • Device accessibility and availability – As vehicles are typically only used for a couple hours each day, the opportunity to perform vehicle downloads and updates are usually during the height of rush hour traffic where other vehicles are also competing for the same network resources creating a delivery and reliability challenge.
  • Device connectivity – Vehicles are often equipped with LTE / 3G modems that are subject to network latency and capacity constraints by the network provider. Mobile network operators may restrict or cap traffic at certain times of the day. Additionally, vehicles are foremost transportation which means they will be establishing connections with many different cell towers to complete a single download as they are in transit.
  • Vehicle / regional jurisdiction and content governance – Regional jurisdiction may regulate where content and software updates may originate from which further complicates the delivery execution for manufacturers.
  • Zero-rating – Allows the manufacturer to work with mobile network operators to whitelist connected vehicle update traffic vs vehicle owner initiated traffic and bandwidth.
  • Security – Mitigating and managing vehicle threats and consumer privacy and data is a core mission critical objective for manufacturers. Ensuring protection for vehicle services and data, or any personally identifiable information is an imperative.
  • Reporting / Visibility – Fleet intelligence, at a glance reporting of total firmware downloads, success rate of delivery, and throughput are some the key metrics manufacturers will need to have visibility on to determine overall success rate of campaigns, and introducing new vehicle capabilities and services.
  • Frequency of Updates – How often will new firmware, patches, and new vehicles services and capabilities be introduced?

Let’s focus in on the frequency challenge as this is perhaps the most important. As software technologists, we come to expect the imperfection of software. Bugs and vulnerabilities are a reality. Addressing each of the above challenges at scale is a monumental task. Many modern vehicles today have over 100 million lines of code. The effectiveness of a vehicle manufacturer to not only identify defects, mitigate threats, and release a patch at scale timely and repeatably will be core to the overall success of Connected Vehicle Operations, and the IoT vision and solution.  Akamai is poised to deliver on each of the above automotive and IoT challenges.

 

Akamai OTA Updates Solution

Delivery

  • Globally distributed platform optimized for mobile / cellular networks. Allows firmware updates to be delivered from an Akamai Edge Server closest to the vehicle and cellular tower.
  • Zero Rated Billing allowing manufacturers to work with Mobile Operators to whitelist firmware update traffic leveraging a small subset of Akamai Anycast IP Addresses.

Monitoring

  • Aggregated Reporting to capture metrics for download completion, throughput, traffic distribution, and more.
  • Low-latency Download Notifications allows the manufacturer to receive a notification at the completion of a download to confirm successful delivery.

Akamai’s Existing Platform Capabilities

Security

  • Distributed Denial of Service / Web Application Firewall protection – Adaptive Rate Controls, Intelligent Application Layer Rules based on anomaly scoring, Network layer controls, and real-time Threat Dashboards
  • Establish Trusted End-to-End communication via mutual authentication and client certificates

 

Contact your Akamai Account Representative for more information on how to address your IoT strategy and Connected Devices. Stay tuned for our next article on best practices for configuring your OTA solution through Akamai to handle 100,000+ vehicle updates per day.

 

 

Note: Above is a major automotive manufacturer ramping up to deliver 100-300MB firmware package to hundreds of thousands of vehicles.

 

[1] http://www.gartner.com/newsroom/id/3598917

 

[2] http://www.businessinsider.com/connected-car-forecasts-top-manufacturers-leading-car-makers-2015-3

 

[3] https://www.wired.com/2016/08/jeep-hackers-return-high-speed-steering-acceleration-hacks/

 

[4] https://www.autoindustrylawblog.com/2015/07/06/a-study-of-recall-completion-rates/

https://www.stoutadvisory.com/insights/report/2016-automotive-warranty-recall-report

Ben Lin

Configuring DNSSEC in Fast DNS

Posted by Ben Lin Employee Nov 30, 2017

DNSSEC (DNS Security Extensions) is a set of specifications that are designed to protect applications from using forged or manipulated DNS data by allowing zone administrators to digitally sign zone data using public key cryptography.  Fast DNS is Akamai's Internet scale, authoritative DNS service that is designed to protect against DNS based DDOS attacks and respond to DNS queries quickly.  Fast DNS can also support DNSSEC enabled queries.  This post will show you how to enable DNSSEC for Fast DNS in the Akamai Luna portal.

 

This procedure assumes that you will create a new Fast DNS zone in Luna and that you be using the "SIgn and Serve" method for DNSSEC.  The benefits of using "Sign and Serve" is that you will be offloading the support of DNSSEC to Akamai which uses the existing Key Management Infrastructure (KMI) for the Zone Signing Key (ZSK) and Key Signing Key (KSK).  When using Sign and Serve, Akamai's name servers must be the exclusive authoritative name servers.

 

From the Luna Menu select Configure -> Fast DNS / Configuration.  Then click ADD ZONES which will present this screen:

 

 

The Zone Type is set to Primary which means this configuration will use the Luna portal or Open APIs (https://developer.akamai.com/api/luna/config-dns/overview.html) to create Resource Records.  Alternatively you can set it for Secondary which means that the Resource Records will be created by DNS zone transfers from your Primary DNS Server.  If configuring DNSSEC in Secondary mode then TSIG will need to be enabled to secure the zone transfers.

 

Click the check box for "Sign and Serve DNSSEC" to enable this functionality.

 

DNSSEC Algorithm will present three options:

1. RSA-SHA1 - (7).  This is not recommended as it is no longer considered secure.

2. RSA-SHA256 - (8).  This is the recommended algorithm.

3. RSA-SHA512 - (10)

 

This configuration is set using RSA-SHA256 - (8).  Please note that once the algorithm is configured, changing it is not self-servicable and requires Akamai to make the change.

 

Enter the zones to be configured in the Zones: box.

 

Click Submit.

 

The next screen will show you the DS record associated with your zone and the DNSSEC specific alerts that can be enabled.  It will take 30-60 minutes for the KMI to generate the keys.

 

 

 

The DNSSEC alerts are:

  • Authorities for Zone do not point to Akamai: This alert notifies you when the NS records handed out by the parent zone's authoritative servers do not point o Akamai DNS nameservers.
  • Authorities incompatible with Sign&Serve DNSSEC: This alert notifies you when some of the NS records handed out by the parent zone's authoritative servers do not point to Akamai DNS nameservers.
  • No DS record in parent zone: This alert notifies you when there is no DS record handed out by the parent zone.
  • DS record points to wrong DNSKEY record: This alert notifies you when the DS record handed out by the parent zone does not point to the correct DNSKEY record for the zone.  DNS resolvers with DNSSEC validation enabled could fail to resolve names in the zone, resulting in denial of service.
  • DS record points to old DNSKEY record: This alert notifies you when a key signing key (KSK) rotation is in progress for the zone, and the DS record handed out by the parent zone points to the old DNSKEY record.

 

 

 

You can validate that DNSSEC is working by doing a dig:

 

dig @{one of the assigned name servers} {a record in the zone} +dnssec

 

The name servers assigned to your account can be found on bottom of the Fast DNS configuration home screen:

 

 

 

The next step is to configure the DNSSEC attributes with your Registrar.  In this example I'll illustrate how to do this with GoDaddy.  

 

After logging into GoDaddy select the domain you want to set up and then select Manage DNS.  Under Advanced Features select DNSSEC.

 

 

Then select ADD.

 

 

The following screen will need data generated for the DS record which can be found in Luna (see above):

 

 

Click Update.

 

It will take some time for the Registrar to update the registry.  Once this is done you can test for the existence of the DS record at the Registrar:

 

dig @{one of the top-level name servers for the respective gTLD}{a record in the zone} +dnssec

We all know that is critical for online retailers to have a fast and reliable website to capture their share of what will be spent online during the holiday season, specially knowing that the online channel is set to be a more popular shopping channel than physical stores this year.

Here are some recommendations that you should consider when preparing your website for this important event:

 

1. Make sure your website is ready for business: Performance is a really important matter when talking about conversions and revenue, however before focusing your efforts on performance, you must make sure your site is fully operational and you have taken care of all security matters. Akamai offers a wide variety of security features that help you maintain your brand equity and let Akamai prevent and react when a website is under attack. There's nothing worse than being taken down during holidays due to security gaps.

 

2. Test early: You are most likely implementing features or updating your site ahead of the holidays, so it's important to make sure these updates are not inadvertently slowing the site down in the process. By actively monitoring performance in staging and pre-production environments, you can ensure that those changes aren’t introducing any performance defects at this critical time.

 

3. Prepare your website for heavy traffic: When preparing a website for heavy traffic, one of the top recommendations is to leverage the Akamai platform by caching as much as possible, this way we'll handle most of the traffic (static content), however you should check that your own infrastructure is capable of handling all dynamic calls, to do this, you have to run Load Tests which can be performed using the Akamai CloudTest solution. The goal of this Load Test is to validate that the website is capable of handling the requests of high volumes of users and identify the breakpoints and bottlenecks where the current infrastructure will fail.

Visitor Prioritization is another feature we offer to virtually scale your infrastructure in case there are capacity issues. This feature is going to engage visitors in a virtual waiting room while resources free up, providing a richer experience than just showing a "site down" message. This feature can be enabled within minutes and it allows you to create policies to target different audiences and maximize server capacity.

 

4. Make sure people can shop from a variety of devices: Cross–device shopping is increasingly popular among American consumers who might find an item on one device, research it on another and then buy it on a third. Now, people shop everywhere: while they’re at home, on a train, in a coffee shop or at work. And each time they use different devices. Having a mobile strategy is essential for user experience and therefore bigger sales. Not having it is like pushing your customers to competitors. It's critical to work on a responsive website, mobile site, mobile app, or a combination of them and have them execute at the highest level.

Akamai offers different features to optimize mobile experiences, within these set of features we can find:
- Adaptive Acceleration: Accelerates web and mobile experiences automatically, using Akamai’s Learning Engine, powered by real user data. Using Automatic Push and Automatic Preconnect, Akamai can push resources or connect to 3rd parties, before they are requested by the browser. Adaptive Acceleration significantly improves the time data arrives at the browser ("Time-to-First-Byte") by 35% or more, and can typically improve the rendering process by 5%.
- Optimize images for mobile apps: Akamai uses proprietary network detection routines to automatically determine if users are on a good or poor network and the device type. Apps can be made aware if they should request big bold images or compressed images. You can also define policies to automatically optimize each online image for the best combination of size, quality, and file format suited for each image and device.
- Support for the latest performance standards: Akamai makes it easy for you to enable the newest Internet standards, like HTTP/2 and IPv6, and the performance benefits inherent in them.
- Mobile App Performance SDK: This SDK effectively extends the Akamai Edge all the way to the user's mobile device allowing you to customize and deliver instant app experiences based on network-awareness, and last-mile optimization technologies. Additionally, this SDK provides real user and device insights, including custom metrics, to help tune mobile experiences over time.

 

5. Speedy sites get the sales: Slow speeds play a huge role in user abandonment on a website. Lightning fast page times are of utmost concern for shoppers and should be for you as well. There are simple steps that you can take to improve the speed of your website like optimize images, only call images above the fold when the page loads, optimize CSS and JS files, defer the execution of JS files, etc. Optimizing experiences is one of the core tasks of Akamai so you have plenty of features to choose from to perform better.

 

6. On the big day - Monitor performance and site outages: You should monitor your business critical systems throughout the year. But, it is especially important when you are anticipating a high volume of users. It’s always better to catch outages or site slowness before you hear about them from unhappy customers. This is a really important step and as you might know Akamai also offers an option to do this. You can leverage Akamai mPulse solution to monitor real time user data and get insights of what's going on with the performance of your site, in order to tackle any performance degradations that could occur before or at the time of the event.

As we saw, Akamai has a lot of features to help you prepare your site for the holidays. You can count on us to have a very successful and profitable holiday season.

 

Ted Shuter, Akamai Ion Senior Product Manager, has started a great series of blog posts on developer.akamai.com around Adaptive Acceleration, a key feature of Ion which provides automatic effortless performance optimization for websites.

 

The following are the links to his latest posts:

 

Make sure you follow Ted on developer.akamai.com for upcoming posts.

 

Thanks!!!

 

E-

Google’s Accelerated Mobile Pages (AMP) and Content Delivery Networks (CDN) are complimentary. In this post I’d like to show that the two can co-exist.

This blog post was originally published here: 3 Reasons Why AMP And CDN Can work together – Akshay Ranganath's Blogs 

What is AMP?

According to Google Accelerated Mobile Pages (AMP) project

is built on top of existing web technologies to enable blazing-fast page rendering and content delivery.

Although Google’s stated purpose is about speed, the adoption has been due to the carrot it danlges for AMP users. A page that implements AMP could be shown as part of the carousal right under the search bar. A non-AMP page will never be shown here. This SEO jump is what has been driving the folks to try AMP. To get into this carousal, you need to have your content in Google’s AMP cache. But - we’re getting ahead of oursleves. Let’s see how AMP works.

How does AMP work?

AMP consists of 3 parts. Again, taken from the AMP project:

  • AMP HTML is HTML with some restrictions for reliable performance.
  • AMP JS library ensures the fast rendering of AMP HTML pages.
  • AMP Cache can be used to serve cached AMP HTML pages. If your page implements the AMP HTML, passes the validation by AMP JS, then you are eligible for AMP CDN caching. Elaborating on the caching, Google explains:

    The Google AMP Cache is a proxy-based content delivery network for delivering all valid AMP documents. It fetches AMP HTML pages, caches them, and improves page performance automatically. When using the Google AMP Cache, the document, all JS files and all images load from the same origin that is using HTTP 2.0 for maximum efficiency.

An immediate question that comes to mind is: Do we remove CDN since we now have AMP and save some money? Well, the answer is you will still need a CDN and here are 3 reasons for it.

team work

Reason 1: AMP pages still need to be hosted

AMP pages are discovered like regular pages by Google. So you need to have a webpage that is hosted on the internet. Here’s a the work-flow that Google uses to discover and cache an AMP page. For details and an example, refer to the case study below.

How is AMP Page Discovered?

Google detects that an AMP version exists by looking for the <link rel="amphtml" tag. Content publishers will potentially need to create 2 versions of a page and host it at origin. Since these are pages that can be cached, serving them over CDN will ensure better performance and a good offload at the origin data center.

Reason 2: Google still needs to index

Google claims that site speed is one of the indicators for ranking a web page. To get to a good performance, you’d need to leverage a CDN. This will ensure that the latencies are reduced for the Google bot, regardless of the bot’s location and your site has a good performance and better chance of ranking well on Google.

Reason 3: AMP is not universally supported

The target for AMP project was mainly publisers. These are the pages that can easily be cached and has little to no personalization. If you are running an website like an online shop with personalized content, A/B tests and device specific optimizations then, AMP will not be a good fit.

AMP is also not designed for pages that have dynamic elements. So if you have a form or a check-out flow, AMP will not work for you. In all these cases, you’d need to host a version of your website and use a CDN to deliver and optimal experience to your users.

Case Study

With the basic story out of the way, I wanted to show a real use case. Let us take the example of Forbes. Let’s use an example of a news story.

Now, this page is the full user experience. If you look at the source code, it has a hint to the AMP page using this tag:

Let’s follow the link and open the AMP page. Within this AMP page at the URL https://www.forbes.com/sites/bobevans1/2017/10/18/ibm-rocks-the-cloud-purists-moan-but-customers-love-big-blues-15-8-billion-cloud-business/amp/, there is a reference to the AMP JS.

<script async src="https://cdn.ampproject.org/v0.js"></script>

This tells Google that Forbes wants the page to be validated and cached on Google AMP cache. So Google does the validation and saves it at the URL https://www-forbes-com.cdn.ampproject.org/c/s/www.forbes.com/sites/bobevans1/2017/10/18/ibm-rocks-the-cloud-purists-moan-but-customers-love-big-blues-15-8-billion-cloud-business/amp/

There is a pattern that Google follows to name the AMP domain. This is explained in the AMP Cache URL Format

Hacks Around AMP

Use AMP without AMP cache

Using the JS code to validate your page is the step that actually causes Google to create the Google cache domain and serve the objects from here. If your goal is to build a well-performing web page but without the Google AMP cache, then simply remvove the reference to the JS file. By doing this, you get the advantage of a well performing page and full control over the content.

The downside is you will not appear in the carousal below search box.

Create AMP-only page

You could create a website that has AMP-only version. In this case, the &lt;link rel="amphtml" tag will point back to the same URL to tell Google that this page is an AMP version.

For example, BMW.com has a new website that is based on AMP (and progressive web app). If you notice the source code, it starts with this tag:

<html amp lang="en">

So this page itself will be served for mobile search results (from AMP cache) and from the regular domain for all other uers.

Concluding thoughts

AMP is targeted for mobile search results and for faster rendering of content on the mobile devices, especially in constrainted network conditions. If you are a web-admin who wants to provide a rich user experience and immersive images, then AMP is not necessarily the right approach. It can give you a marginal SEO boost but, at a cost of minimalistic experience.

Regardless of the approach you use, there still needs to be a web site that is hosted. This website still needs to be fast, reliable and scalable to handle the end user and bot requests. It can either provide a minimalistic AMP experience or a rich experience. For this part of the website, you would require a CDN and hence the argument that AMP and CDN work together.

Network Administrators, Performance- and Support Engineers might be quite familiar with these 2 network diagnostics tools:     Traceroute and MTR (Originally Matt's Traceroute, now called "My traceroute" or just MTR). 

 

There are versions for Unix and Windows operating systems, but their native environment is Unix and network devices (routers and switches). As protocols, Traceroute on Unix  typically use UDP (high port #) vs on Windows it uses ICMP echo requests.

 

In this Blog I will very briefly discuss:

 

  • How traceroute/MTR works
  • How to interpret traceroute/MTR reports
  • Understand network latency and loss 

 

How Traceroute and MTR works

 

Traceroute/MTR works through the Time to Live (TTL) field in the IP header, also called: hop limit.

When a packet is sent on the internet, that packet is given a TTL to avoid routing loops.

When it has traversed as many router hops as the TTL, the packet is discarded and a "TTL Expired" packet sent to the Source or Sender. When the final destination IP host is reached, it returns an "ICMP Dest(ination) Unreach" which completes the Traceroute.

 

 

 

How to interpret Traceroute/MTR reports

 

Let's take a look at a sample MTR report:

 

$> mtr hostname.com
          Host                                     Packet Loss% Pings Snt Last Avg Best Wrst StDev

  1. a104-103-235-2.deploy.static.                   0.0% 19 0.2 0.5 0.2 5.9 1.3
  2. sea-edge-13.inet.qwest.net                       0.0% 19 0.4 1.6 0.3 23.0 5.2
  3. sea-brdr-02.inet.qwest.net                        0.0% 19 0.5 1.0 0.4 10.6 2.3
  4. lag-10.ear2.Seattle1.Level3.net             10.5% 19 0.7 0.7 0.7 0.8 0.0
  5. ae-24-24.ebr3.Atlanta2.Level3.net         55.6% 19 6337. 6558. 5526. 7095. 549.2
  6. ea.ear2.SanJose1.Level3.net                    0.0% 19 18.9 18.9 18.8 19.8 0.0.0

 

A typical MTR report lists (by default) the rDNS entry of the router (host name), followed by the packet loss in % , the count of pings sent (19), last-, average-, best- and worst Round trip time (RTT) in milliseconds.

 

 

Understand Network Latency and Loss

 

Do you see anything wrong with the above MTR report? Is there an issue? 

Absolutely not! There is no issue. The 55% loss and 6k ms latency seen in hop #5. is often called "Fake latency".

 

There are several possible reason for middle hop loss/latency that is not carried forward (to last hop):

  • Equal Cost Multi-path - Packets can be spread over the different links (Asymmetric Routing)
  • Router (CPU) is busy. Modern routers are designed to pass (ICMP) packets through - packets the router must act upon (an ICMP TTL Expired packet) or creates take much longer.

 

Remember: the "Last hop" is all the matters. Packet loss in the middle mile can be ignored, as long as it is not carried forward.  ICMP is often rate limited on the internet due to how it can be misused (port probing, flooding). 

 

Let me repeat that: the LAST HOP is all that matters.  if there is no loss or latency seen in the last hop, the network path is perfectly fine. Always consider the latency/loss to the final hop when evaluating an MTR/Traceroute report. 

What causes Latency?

  • Propagation delay (a packet's time to travel the distance between point A to B, speed of light in fibre) 
  • Queuing delay (Congestion on a router)
  • Serialization delay (time to physically create and put the packet on the wire) 

It's Halloween. I'm sure numerous readers are much more terrified of what could happen in 3 weeks, rather than ensuring the appropriate amount of treats are available for any trick-or-treaters this evening. Fear not! Manuel Alvarez and Dominic Lovell from the consulting team here at Akamai have just released white papers on Feature Toggle and Dark Releases, and Handling Flash Sales. Both of these are very applicable to major traffic events, especially black friday and cyber monday. We took our experiences across customers and consolidated our best practices and insights in to these documents that can be utilized by anyone that has a hand in event preparedness, whether its marketing, product, engineering or operations. 

 


 

Handling Flash Sales
Major sales events can be great opportunities for online businesses but can also be nightmares if you haven't planned appropriately for them. What aspects of my site's architecture truly impact my customer's online experience and how much do I really need to prepare are two of the common questions we receive from our customers. In this white-paper from Akamai's Global Consulting Services team, we investigate what is really necessary when it comes to preparing for your highest level of traffic, whether it is during Black Friday or a random Tuesday.

 

https://www.akamai.com/us/en/multimedia/documents/white-paper/handling-flash-sales-devops-strategies-for-traffic-mitigat… 

 

Feature Toggle and Dark Releases
Typically these types of features aren't thought of as "holiday readiness", but they can (and should be) leveraged as a part of preparing for peak traffic. Ensuring your major sale page(s) or product page(s) are live and available to the right audience at the right time, are paramount to a successful event. In addition, creating a backup online experience if the worst should happen and planning for this unfortunate scenario are both covered in this white-paper from our Global Consulting Services team here at Akamai.

 

https://www.akamai.com/us/en/multimedia/documents/white-paper/feature-toggle-and-dark-releases-whitepaper.pdf 

 

If you have any questions, please feel free to comment below or email consulting@akamai.com.

This blog post will provide Akamai’s recommendations for settings in our Certificate Provisioning System with the goal of keeping your traffic secure and your settings up to date.

 

Our overall philosophy is that a brand new certificate with all Akamai defaults should be capable of achieving an A on SSL Labs. However, as our customers all differ in their ability to accept and roll out changes, we leave upgrading existing certificates to the discretion of our customers unless there is a severe vulnerability announced with any particular setting which necessitates immediate action.

 

If you’d like to test any changes on staging prior to pushing the change to production, please enable the “Change Management” feature that is on the “Deployment and TLS Metadata” tab; this is the Always Test on Staging feature on our Beta User Interface (UI). This setting change is immediate regardless of how you got to the Deployment and TLS Metadata tab and can even be enabled from the “View Enrollment” action.  Please note that even with "Change Management" and "Always Test on Staging" enabled, seven days before the active certificate expires, any new certificate on staging will be immediately deployed to production unless a later deployment date is set.

 

Certificate Creation:

Geographical Deployment:

“Excludes China & Russia” is our default option which provides global coverage but does not utilize Edge servers inside of China or Russia; those countries are served from outside the borders. Our China CDN and Russia CDN options are available to serve traffic from inside those countries. If both China and Russia CDNs are required, you will need two different certificates with our Global Traffic Manager in front to decide which certificate to present.

 

SNI-Only:

Server Name Indication (SNI) Only delivery allows Akamai to serve multiple certificates from shared IP addresses. SNI-Only on provides for faster service at a lower price! If SNI-Only is off, traditional VIP based delivery is used where each certificate will utilize a dedicated IP address per Akamai region. SNI only should not be used if you need to support Windows XP, Java 6 or lower, Android 2.3 or lower, or any custom application that does not support SNI. Please see this blog post for a good discussion on SNI usage.

 

Certificate Chain (for Akamai-managed Symantec OV):

The default chain should be used in all cases unless you know for sure that you have legacy devices such as TVs, set top boxes, printers, etc. that have a trust store that cannot be updated and must use the cross-signed 1k root option.

 

“Default” is the setting for new certificates.  However, Symantec certificates that were transitioned from Verizon Cybertrust have the “Cross Signed 1k root” option on. All of these should be updated to “Default” unless you have the situation above. 

 

The “Cross-Signed 1k root” option will cause SSL Labs and other PEN testing services to report a weak certificate chain with a SHA1 certificate. This warning can be avoided by changing this option to “Default.”

 

An up to date listing of all Akamai managed certificate chains can be found at this blog post.

Deployment Settings

Hostname Must Match CN

Leave this setting on unless you must CNAME a test hostname to the same edge hostname without adding the test hostname to the certificate. Also, if this is needed for testing, it is recommended that is only done on a QA/test slot. Having both production hostnames and QA/test hostnames on a single certificate is also not recommended.

 

Client TLS Renegotiation

This one is confusing because our default is not the same as our recommendation and our recommendation will cap the SSL Labs score at A-.

 

“Secure” is our platform default which allows clients to securely initiate a renegotiation of TLS session parameters, ciphers or keys. This setting will allow up to an A+ in SSL Labs.

 

We believe it is actually more secure to “Disallow” renegotiations all together, however, SSL Labs caps this setting at an A-. The good news is this debate goes away in the future as TLS 1.3 does not support client renegotiation.

TLS Protocol Versions

“Use Akamai Defaults” selects the Akamai defaults at the time of certificate creation.  At the time of this writing they are TLS 1.2, 1.1 and 1.0 in that order. When TLS 1.3 becomes generally available in early 2018, certificates with “Use Akamai Defaults” will include TLS 1.3 if they also have a cipher profile supporting TLS 1.3.

 

See this blog post for a good read on TLS 1.3 and what it takes for it to become an internet standard.  Please also see this blog post for details on our TLS 1.3 beta.

 

Our TLS 1.0 deprecation plans are still being finalized. Customers wishing to remove support for TLS 1.0 should use the “Disable Specific TLS Versions” option to disable TLS 1.0. In order to remain PCI compliant, for customers that need to do so, TLS 1.0 should be disabled prior to June 2018.

 

WARNING: At some point in the near future we will change the selection of specific TLS versions from “disable” to “enable.” Please pay attention to to the User Interface prompts when making TLS Version selections.

Enable SANs

SNI Only certificates provide an option of controlling which hostnames are actually active for that certificate. By default, all of them are enabled. This option allows you to tell Akamai to not serve this certificate even if the hostname is presented to an Edge server. This option can be useful when moving hostnames from one certificate to another. Be aware that if the same hostname is enabled on multiple SNI Only certificates, the Edge server will randomly choose which certificate to present.

Dual Stack RSA+ECDSA

Available today for Akamai-managed Symantec OV/EV and coming soon for Let’s Encrypt DV, this option provides an ECDSA copy of the certificate to be on the same slot as the RSA certificate. CPS will keep both certificates in sync with each other. The ECDSA certificate makes connections with modern devices more efficient.

 

Dual Stack is on by default for new certificates. Customers wishing to make use of this for existing certificates are required to specifically enable this option in CPS.  

 

Be careful with this option if you make use of any kind of client certificate pinning as there will be two certificates clients can connect to.  

OCSP Stapling

The OCSP Stapling option can be enabled to staple the OCSP response along with the client’s request for the certificate. This will save the client from doing an additional round trip to a 3rd party hostname to obtain the OCSP response, making initial connections faster. If no specific selection for this setting is made, OCSP stapling will be enabled the next time a certificate or deployment setting change is made.

 

OCSP Stapling is available for all Akamai managed certificates and is currently only available for some third-party certificates. We recommend enabling this feature as we don’t see any downsides with it.

Cipher Profiles

For cipher profiles, our latest defaults and recommendations will always be listed at http://akamai.me/CipherProfiles. Please follow that page (click on following and inbox) to keep up to date as we release new profiles. Please note that if you still require Windows XP/Server 2000 clients to connect to your site, you should choose ak-akamai-default-2016q1 which is the last cipher profile to support DES-CBC3-SHA and currently still can achieve an A on SSL Labs. ak-akamai-default-2017q3 is our current default and contains the ciphers necessary to support TLS 1.3.

 

Property Manager Settings that influence SSL Labs Score

 

The defaults described above will be sufficient to achieve an A on your SSL Labs Score. In order to achieve an A+, you need to enable HTTP Strict Transport Security (HSTS) headers with at least 6 months duration. HSTS headers tell a browser that it should only connect with HTTPS. These headers can either be set at the origin or you can utilize the "HTTP Strict Transport Security (HSTS)" behavior in Property Manager. This behavior is included by default for new secure properties, however, it is not enabled.

 

Please be careful when including all subdomains and using the preload option as a denial of service could result if the subdomains or any portion of the site still requires HTTP.


We do recommend using HSTS headers, but only do so if your entire site is enabled for HTTPS delivery. When enabling them, start with a shorter max age and then increase it as your confidence grows.

During the annual Edge Conference in Las Vegas, Akamai introduced the latest updates to Ion. 

Akamai Ion can help you deliver rich, personalized experiences to your users faster and more easily than ever before, using Akamai's machine learning engine to determine optimizations from real user behavior, and without recurring effort.

 

Below is a list of the key features that Ion provides, and the best thing, all of these great capabilities are available today, at no additional cost, for any Ion Standard, Ion Media Advanced and Ion Premier customer, by simply enabling them in the Akamai customer portal:

 

  • Effortless Browser Performance:

    Automatically adapt to site changes and users with Adaptive Acceleration (click here for more details). Effortless machine learning technology to determine performance optimizations from real user behavior:

    • Learning Engine: Uses real-user data to automatically determine optimizations.
      • Critical path identification new!
      • Mobile and desktop detection new!
    • Automatic Push: Leverage HTTP/2 to push content to render earlier.  Added H2 priority protocol to ensure critical resources arrive first new!
    • Automatic Preconnect: Accelerate 3rd party connections with W3C Preconnect
    • Resource Optimizer new! : Brotli and Zopfli to reduce the size of critical resources
    • Script Management beta! : Track and manage the impact from 1st and 3rd party scripts

 

  • Best Mobile App Experience:

    Drive greater application engagement optimizing mobile user experiences across variable network types and connectivity conditions:

    • The Mobile Application Performance SDK is now available to all Ion customers, including Ion Standard
    • Universal Cache new! :Honors cache control headers for all requests passing through the SDK to allow your app to be more resilient to network fluctuations
    • Network Awareness: Optimize apps based on networks quality data
    • Adaptive Network Optimizations new! :Identifies the optimal network profile depending on the connecting network quality, connection type, carrier and device type
    • SureRoute for Cellular: Identifies the optimal ISP region behind a mobile packet gateway to fetch content across a cellular network.
    • Content Prepositioning: Push content to the client during times of high network availability, in order to have that content at the ready when the client needs it. Preposition popular content new!
    • Analytics and Reporting: Improve app performance by identifying bottlenecks; measure both standard performance events, such as time-to-first-byte, as well as custom events within the app

 

  • Maximum Agility for Developers: Go beyond caching with powerful edge capabilities, integrating Akamai’s Cloud Delivery Platform into your existing DevOps workflows via a programmable, automated, and repeatable interface (Akamai for DevOps):
    • Fast Activation: Deploy custom configurations globally in less than 10 minutes (3 minutes in test environments). New early testing and configuration validation configuration allows developers to deploy a new configuration and test it quickly before it goes across the platform new!
    • Fast Fallback: Return to a previous stable configuration in seconds to reduce risk associated with new optimizations and configuration changes new!
    • Fast Purge: Adds purge by URL, by CP Code, and by Cache Tag to gain flexibility and precision in maintaining control over cache controls new!
    • Property Manager API Custom Behaviors: Custom behaviors are read-only, like advanced features, but they’re designed so that users can apply the same customized XML metadata to many properties at a time. Now custom behaviors allow users to reuse advanced metadata between configs new!
    • Onboard & Configuration Assistant: Support for Adaptive Acceleration and Image Manager Configurations to onboard more quickly new!

 

Please log into your Akamai customer portal, where you will be able to try Ion via the Marketplace, or if you are an existing Ion customer, activate and use features like Adaptive Acceleration.

In January 2017 Akamai announced that we funded the OpenSSL Software Foundation to accelerate their plans to support TLS 1.3 in the OpenSSL cryptographic library. This code library is one of the leading libraries used by servers and clients (including Akamai’s networks) to secure SSL/TLS connections on the internet. TLS 1.3 is a significant overhaul of the protocol that secures HTTPS communications, aiming to improve performance (and end-user experience) and close architectural vulnerabilities in previous versions.

 

Today, we are announcing our plans for support for TLS 1.3 on the Akamai Secure CDN.

 

TLS 1.3 Beta

Later this year, we will start a beta program for TLS 1.3 for customers with custom certificates (those on the Secure CDN). If your web property is secured by a custom certificate, you will be able to enable TLS 1.3 during the beta period. No additional beta paperwork or agreements are necessary to participate.

 

There are now controls in our Certificate Provisioning System (CPS) to configure your custom certificate for the upcoming TLS 1.3 beta. Your certificates will need to be configured with two specific settings. In either the existing Certificate Provisioning System (CPS) interface in our Luna portal, or the new beta interface of CPS, edit the certificate and perform both of these steps:

 

On the “Deployment and TLS Metadata” tab (or “View and Edit Deployment Settings” screen in the CPS beta interface):

  1. Select Enable all TLS versions
  2. Select the ak-akamai-default-2017q3 cipher profile.

 

The new ak-akamai-default-2017q3 cipher profile is the same as the previous-default ak-akamai-default-2016q3 cipher profile, with the addition of TLS 1.3 ciphers. This new profile continues to support all previous TLS versions and can be used to support non-TLS 1.3 clients. See SSL/TLS Cipher Profiles for documentation on the currently available and recommended cipher profiles.

 

Once the TLS 1.3 beta is turned on network-wide by our operations team, your secure properties configured as described above will be enabled with TLS 1.3. This new TLS version is still working its way through the IETF standardization process, and as such different crypto libraries, web servers, and browsers have implemented different, non-interoperable draft versions. Akamai and OpenSSL have implemented Draft 21 of the TLS 1.3 specification. We will be moving to the final version after it is ratified as an RFC. Clients will need to have implemented the same version in order to connect with TLS 1.3. The IETF TLS Working Group maintains a list of TLS 1.3 clients and their implemented versions.

 

For certificates enabled in this beta, some standard Secure CDN features will be unavailable. If your secure properties depend on these, those certificates should not be enabled for the beta:

  • Client certificates (mutual authentication) for clients connecting to the Akamai edge (client certificates for origin connections will continue to function)
  • The ability to select TLS 1.2 and 1.3, but deselect TLS 1.0 and 1.1 (necessary for PCI DSS 3.2 compliance), for a specific certificate
  • TLS 1.3 enabled in conjunction with ciphers necessary to support Windows XP
  • TLS interception devices (“middleboxes”) which have not been upgraded to recognize TLS 1.3 connections

 

TLS 1.3 General Availability

After the TLS 1.3 specification is approved by the IETF, we plan to make TLS 1.3 generally available (GA) for all web properties on the Akamai Secure CDN. TLS 1.3 will be available as a platform feature, for all customers and delivery products. At that time, you will be able to continue to select “Use Akamai Defaults” and select the “ak-akamai-default-2017q3” cipher profile. After GA, the Akamai default list of TLS protocol versions will include TLS 1.3.

 

Future functionality

We will be enabling TLS 1.3 with the Akamai shared certificate in 2018. We are also investigating support for additional TLS 1.3 features such as origin connections and 0-RTT early data.

 

Timeline

Available now: controls in CPS to enable the TLS 1.3 beta.

Late 2017: TLS 1.3 beta turned on network-wide.

Early 2018: TLS 1.3 will be generally available (GA). All newly-configured certificates will have TLS 1.3 turned on by default. To enable TLS 1.3 for existing certificates, simply update the cipher profile to “ak-akamai-default-2017q3”.

 

If you have feedback on this new beta capability, or have issues, please reach out to Akamai Technical Support through your normal support channels. You can also follow this blog post to be notified when new Beta features are available.

Filter Blog

By date: By tag: