Symantec Webinars - SHA1 Deprecation_with intro
0 (0 Likes / 0 Dislikes)
On behalf of the Symantec Corporation Trust
Services business I would like to welcome
all of you joining today and thank you for
choosing Symantec as your solution provider.
My name is Frank Agurto-Machado,
senior systems engineer
in Trust Services and I will be
your presenter for today's event.
We're happy to speak to you today about the
SHA-1 deprecation and what you need to know.
With that we'll go ahead and begin.
Before we begin, let's
discuss today's agenda.
We'll be focusing on some terminology
and maybe some quick housekeeping,
so we'll talk to that for a little bit. We'll
definitely talk about the Symantec migration path
and what the Symantec plan is there. A recap
on the certification authority browser forum
or CAB/F baseline requirements for SHA-1
deprecation, the browser interpretation
moving forward and what you need to be ready
for. Remember this is with current browsers.
Last we'll discuss Symantec being your security
partner along with questions and answers,
and how we're going to be there to assist you.
And of course at the very end we'll have
a question and answer period as well
with the time left on the web seminar.
So with that we'll go ahead and begin.
So let's discuss some terms you will
hear throughout the presentation.
For those who are familiar with or
dealing with the situation already,
a lot of this is probably par for the
course; for those who have not been
dealing with the situation or not been dealing
with the SHA-1 deprecation requirement
on SSL certificates in your enterprise,
this is good to know information.
So let's talk about SHA-1:
secure hashing algorithm one.
It offers messaging hashing sizes
at about a 160-bit message digest
It's been here for quite a long time.
From a Symantec perspective we've been
using it even when we were at VeriSign
Incorporated, we were using SHA-1; we
stopped using message digest years ago,
because we felt it was eventually going;
it wasn't a matter of if, but
when it was going to be broken,
and it was, of course.
So we've been using it for years
prior to the industry requirement to go
to SHA-1 - from message digest to SHA-1. OK?
As a matter of housekeeping under the SHA-1
before I move on, some of our roots out there
were signed under message digest too; we
simply changed those for a matter of just
good housekeeping or uniformity: we didn't
have to change them in the industry,
but again we did this because of course the look
of uniformity throughout the root hierarchy,
but always remember that our roots are kept
offline; they're kept in Symantec data centers,
which are not known, of course, and are well
secured, and we use military-grade data centers etc.
For the online CAs as well that are signed
under SHA-2, even the SHA-1 versions
they are also kept in Symantec data centers;
we do not use third parties for hosting
or third-party personnel; they're
all done by Symantec personnel
based on our own security infrastructure
requirements, OK? So with that we will move on.
So SHA-2, this consists of six suites, two of which
are truncated under the SHA-2 512 functionality,
so for all intents and purposes, what you
would see being used in the industry
will only make that equivalent to four
crypto hash functions that are out there:
SHA-224, SHA-256, SHA-384, and SHA-512;
at the end the last two are truncated
so again, you might see that if
you look at Wikipedia or some other
technical definition website you
might see that as well but I
wanted to make sure I explained that
through, that from an industry perspective
of what's tangible or consumable
by the customer, by Symantec's customer
in this case, you would see four functions
being used in the industry - but again,
from our perspective of what Symantec's
doing, we're not really touching SHA-224.
It's not really being used too heavily and
we immediately advanced from a
proactive perspective to SHA-256, but as a
matter of FYI for those who are listening,
we also have a SHA-384 root out
in the industry, so at some point
you might see that being utilized and if it
is, it's already out there.
And again, this is what we do as a thought
and leadership provider in our industry:
we tend to park roots
out there very early
as our SSL architects look at the
industry and see how it's changing,
we listen in to the governing bodies above
the CAB/F and that kind of dictates where
things will be going, and for those who
have been paying attention to that as well,
you may see things like elliptic curve, digital
signature algorithms, those kind of things
coming to light, not necessarily industry
standard but definitely becoming more
and more popular because now
you start getting security and
functionality or performance together:
with elliptic curve as an example,
so again, without getting off course, that's
why I've talked about six crypto-functions,
though really there's only four that will
probably be readily available for the industry,
and again a lot of that is going to be
based on industry support,
so that's web browser vendors,
web applications, etc.
Let's talk about a term that's pretty
familiar: SSL: secure socket layer.
It's basically a secure communication
protocol between you know
your traditional client-server environment.
Client is a more metaphorical term
because you have server to server,
device-device, things like that
that connect to host, that act as a server or
I probably should even say client host, but
again it's done over HTTPS for the most part,
right, whether you're doing HTTPS over SOAP
or any other kind of developer based application
out there; again, secure socket layer
has many uses, of course: that's kind of
the premise of this discussion.
So, Certificate Intelligence Center.
For those who have not dealt with our enterprise-based
solutions this will be very definitely
a very foreign term, but for those who
have heard it before, it falls under our
enterprise solution that we call managed PKI
for SSL, not Symantec Trust Center Enterprise.
It falls under more of the
larger scope of the solution.
We call it MSSL, but again it's more of a
holistic SSL discovery and automation,
but it's more of an option at
this point, and again it's a holistic
discovery of all SSL certificates in an
enterprise ecosystem, right, so not just
the Symantec SSL certificates that are
residing out there; Certificate Intelligence
Center or CIC can touch everything SSL
based on what the administrator decides
they want scanned, and of course it works
based on port or socket criteria which is
IPM port assembly. OK so again you're going
to hear that later on in the presentation.
So let's talk about certificate
authority browser form or the CAB/F.
For those that aren't familiar with the CAB/F,
it's not necessarily the upper governing body
like the IETF or the NIST or any
organization like that; it's more kind of
a buffering governing body between them and
us, us being not necessarily public CAs
but also the consumer who buys
public CA-based products,
so really it's kind of a governing body of
best PKI practices, in this case for SSL,
within the Internet community and is comprised
of all public CAs and browser vendors
so not
necessarily web application vendors your
IBMs, your Ciscos who use or take
advantage of open SSL but even
OpenSSL as an organization are not
necessarily bound to CAB/F but us as
public CAs and browsers, we are, because we
work very close together as you see
today with browsers how they respond to SSL-based pages, so a lot of what we do
in there again as public CAs and
browser vendors can become almost some
levels of uniformity, so really in the
beginning it was designed under Extended
Validation - for those who aren't
familiar with that, that's the green
bar that's in your address bar that
your extended validation certificates
will give you, but the premise of that,
of Extended Validation, is a uniform way
of authentication and without beating my
hands on my chest from a Symantec
perspective that uniform way of
authentication was literally we used to utilize it
at Verisign but under our authentication
team we did that for years and what we did is
kind of watered it down and generalized
it so that other public CAs as well to
could follow this basic standard of doing
which is an additional seven steps of
authentication of issuing EV certificates
but again going back to the premise
that's what created the CA browser
forum; and again, us working with
Microsoft and some others, and others
agreeing to jump on, and again now the way
the CAB/F works in the community is more like
an umbrella, so it's more now an umbrella
governing body that kind of says look,
these are best PKI practices to best
protect the customer, not necessarily to say this is
what NIST want so we'll just do it, and
and and by no means am I saying
this in a pejorative or anything like
that but in a sense that this is the way
that we will do this is a way that
best protects the customers so we'll apply these
practices to our browsers and public CAs to
to an issuing certificate. So a long
story short, think of it as if I
had to put pictures - I'm a pictures guy - at the
very top you have your governing bodies like NIST
and IETF and some others, ICANN etc,
IANA, and then under that you would
have CAB/F and under that you would have
everything enterprise network that falls
under all our customers, OK? So we're kind
of putting it into some perspective there.
And last but not least from a terminology perspective
let's talk about the Symantec/Verisign Root CAs.
Unfortunately that can still
be a little confusing.
It's been almost three years and some
change, a little bit longer, since
the Symantec acquisition of VeriSign
trust services or certificate services,
which basically is all our certificates,
managed PKI, our retail certificates
our device certificates, our client PKI
certificates; anything that can basically
warrant a certificate under that service was
purchased by Symantec, but the roots,
because they have such a long longevity
or they have longevity and they're
more rated by generation as opposed to
you know it's only good for a few years
root CAs can last as long as 20 or 30
years so you'll still see the VeriSign
name on there, but those VeriSign roots
are maintained and owned by Symantec,
so they're VeriSign in name only and I
say VeriSign not VeriSign Incorporated,
and again they're fully owned and
managed by Symantec personnel
in Symantec data centers. In some cases the
security model has been drastically changed there,
and I say that in a positive way, but
again there's no kind of outsourcing
or anything of our Root CAs:
the offline root key pairs are again
kept in HSMs in Symantec data centers;
the online root CAs are the same model;
but again all maintained
and owned by Symantec.
So go and take a second longer
look at that terminology page,
and then we'll go ahead and move on.
OK, so let's talk about migration path.
This is the SHA-1 Sunset
requirements and the CAB/F BRs.
Again for those who aren't familiar with
the CA browser forum, BRs are baseline
requirements: this is kind of the baseline,
right, like any policy that we have,
we don't want to talk about that we're
not talking about that pejoratively,
we are talking about just
on a normal day where
all the lights in the lab are working and the
sun's shining this is just normal, how things are
supposed to work and this is from an
industry perspective, but when we use the
term sunset we get more kind of into
the Symantec world of how we do things,
so we always use what's called
a sunsetting methodology
and we did this at Verisign and we do this now at
Symantec, because Trust Services
kind of rides on its own little island and we've
had such a successful run of the way we do things
that we're allowed to keep a lot of those
policies in place because they work,
so again we're not fixing it, because
it's not broken; if anything we're
tweaking it and ratcheting it to make that policy
work even better for customers, but sunsetting
has been something we've done for a
really long time in the trust service world:
sunsetting means that we're really
only as strong as our weakest customer
we'll only move as fast as our slowest
customer, and again I don't want to
put those or make them sound derogatory
towards customers that aren't updating quickly,
but we do have to take all
of that into consideration,
and so what we say this SHA-1 sunset
requirement is, is always think of it as
is the farthest we can go out to allow
you as our customer to utilize SHA-1,
so from the perspective of looking at, you
know, what our public pages are issuing
certificates or what we call the
Symantec Trust Center and
Trust Center Enterprise world, back in October and
December 2014 there were three basic
things that happened there in that time
frame: we changed our default signature
to SHA-256. Doesn't mean you could
not still use SHA-1, doesn't mean
mean it's still not available today per se
but again we made it the default function,
so ideally we want you here but if you
can't we can still allow you to kind of
go there so to speak and then the
end validity for SHA-1 certificates was
established as no later than 01/01/ 2017
and again I don't mean this as a
pejorative but you may have seen in
Microsoft's blog they stated look, 01/01/2017,
we're going to start doing something, put
those SHA-1 roots out there, maybe we'll
remove them, maybe we will turn around and
we'll disable them, well I'm really not but again
I say it kind of loosely because I've seen it
if you were a part of the 1024 to 2048
change there was kind of this wishy-washy
gray area stuff happening out in the
industry right, and again I don't mean
that to point the finger at one vendor or
anything it's more in a sense that just,
you know, changes happen, and as the security
landscape adjusts it's a ripple effect
on what it does to web applications,
what it does to browsers,
what it does to public CAs and how they
operate in the community, so sometimes
you just say OK, no, we're going to do this
without a doubt, OK, because they loosened up
maybe we'll loosen up here as well,
so again you kind of see this change,
but what the the bottom line is here,
where I'm going here, the direction
I'm going here is that Microsoft came
up with the 01/01/2017 date, and that's
a really good hard line; it's got some
distance; it gives customers time to kind of
have that cushion, to start getting ready
for adjustment, and again we established
that date as well. And then the last, there,
the SHA-1 functionality is going to be removed
12/31/2015, so the way I like to say it to
customers - and I kind of say it, you know,
facetiously - is kind of "smoke
em if you got em", right, kind of
an old naval term, right, when back in
my old military days I'd be on the
boat going afloat somewhere and
again they would say the smoking
lounge and I am by far not a smoker,
but not to get off on a tangent
it was that, you know, you use the
same terminology, now is a time where you
better take advantage of it, right, as it's
not going to be here very much longer,
and that's kind of the way I try
to position it for customers when
I speak to them is that is that you want
to take advantage of it now to set up
your cushion, and so what does that mean?
That means if we have certificates
expiring in 2016 we’re going to honor them,
but now is the time to get those issuances
out there because of the fact that of course
it's going away by the end of this year.
So does that mean you wait till 23:59 you know
on 12/30/2015? That's completely up to you,
but the bottom line is to make it clear to our
customer base that it is going away this year;
you should be ready for that; and for
those who haven't planned for this
we really want to start paying attention
to what's going to be happening,
because of course this is industry
standard; this is not, this is happening
to the whole internet community right
this is not something Symantec, you know
got all wild here and said OK we're going to
start doing this is just the best way to go;
this is an agreement between all public
Certification Authorities and browser vendors,
right, and if you look at technology
from appliances to web applications
that reside on those appliances,
they're all adapting very quickly.
Take OpenSSL as an example: it already supports
elliptic curve and DSA and things like that
so from a conglomerate organization standpoint
of multiple vendors and their OpenSSLs
adapting very quickly as well so
they see the changes and the good
things are coming from them and they're adapting.
OK? So let's take a second look at that.
Before I move on I'd like to go into a polling
question and that way we can go from there.
So give me one second here. So what I'm
going to start with: Have you run into any
challenges with SHA-1 deprecation and of
course it has multiple choice so go ahead and
take a second and let's start going to get
those votes out there if you can please.
And again I'll repeat the question: Have
you run into any challenges with the SHA-1
deprecation so far and of course yes I
can't locate them; B) maybe yes I'm having
some compatibility issues, which we have seen:
as an example, some appliances out there,
the version of web application they're
using says it supports SHA-256,
but when you go to use a SHA-256 cert it
doesn't work, but you put your SHA-1 cert on,
it works with flying colors, and that's
from a real-world example that I ran into
with some of my customers. Again I am
not going to say vendors' names because
I don't say it's a vendor issue per se; I
think that it's just, you know, adapting
web applications and the ripple effect that it
creates when utilizing whether it be the
suite sizes under SHA-2 etc. and of course C is,
you know, maybe everything's working just fine;
D and E: maybe we're just not there yet; maybe
I'm finally getting around to it; you know,
maybe depending again on the
size of the infrastructure and the
footprint that I'm applying this to, but again
take a second, go ahead and answer those.
All right. Let's go ahead and move on. So
in this light let's talk about the CAB/F.
Let's do a little more of a recap of what
the CAB/F's been doing thus far,
and we'll go back to about 2012. So again let's
talk about the timelines a little bit further.
As you may recall, the migration from MD5
to SHA-1 came to a close in about 2012.
This was the most recent change
in hash algorithms, right:
We were using message digest and we
switched over to SHA-1; but we
from a Symantec perspective, and
again I'd like to say it as being the
leader in this space, we were using SHA-1
a very long time, much prior to 2012
we'd already adopted SHA-1 and we knew
it was just the better way to go, but
again this speaks to how it got comp...
how again this message digest could be
compromised, and again like I said
earlier SHA-1 is just the better way
to go. But it's just that for us it was
just a matter of re-signing our roots, we
didn't necessarily need to re-key
everything, right, re-key meaning we needed
to create new key pairs and so forth: we
literally just re-signed, so an example: if
you have an older message digest version
of a root out there and then we
resigned as SHA-1, it's the same
key pair, so both will actually work to
authenticate the SSL session, and again
so we take ubiquity into consideration
because part of what keeps
us as one of the best CAs on the internet
is our levels of ubiquity, so as a
percentile of how far our root
is integrated into point of sale devices,
mobile devices, older and new tablets,
different versions of the Android OS, etc
so again we have to look at sometimes
just re-signing we don't
necessarily re-institute the wheel in
that area, OK? And again we did it
to the entire hierarchy of course, because of
course it's a matter of continuity, right, so
putting SHA-1 here SHA-2 there and
MD here doesn't make a lot of sense,
so again, uniformity is the
best way to go, and again it's
being proactive from our perspective as
well and again remember that the roots
that we've done this to are maintained on the
Symantec back-end: no third parties;
we're not using off-the-shelf solutions; these
are things that we built from the ground up.
And the reality is this is why you see
the cost that runs in our products,
because we do this ourselves; we
don't rely on third parties; we are not
making you rely on us that we rely on a
third party, right: it's not a
contract relying on a contract etc.
we're not outsourcing this stuff; these are things
that are homegrown and that we do ourselves.
That doesn't mean we don't use third-party
products: we absolutely do; we just don't
use pre-built off-the-shelf solutions.
These are infrastructures that
we designed ourselves from the ground up
to ensure that we're providing the best
throughput and the best levels of security
for our customers, but again I digress; let's
get back on track to see the browser forum.
But again, remember that our
roots are offline, and so when
you see roots that are not necessarily signed
in SHA-1 it doesn't mean that that root
is prone to attack because in order for
that to happen, that hacker or
teams of hackers would have to attack
us at Symantec and if you notice there's a lot of
articles out there too, some on LinkedIn and
some other areas on I want to say eWeek
and some others that have talked about why
some of the bigger CAs aren't being attacked:
it doesn't mean we sit there beating our
hands on our chest and saying hey,
know we're not worried about it, but
we put a lot of money back into what we
do, because is this is what
we do as a security service
under the Symantec umbrella, but it
doesn't mean that we won't ever be
attacked; no, and I'm not inviting that
by any means, but it means that we put a
lot of money back into there. Is it really
worth someone's time to try to come after us?
Probably not in some cases. Now is it worth
trying to intercept at the customer level?
Absolutely. Does it make the customer
a target? Sometimes it does,
but the bottom line is from a security
perspective what we do with our roots
our roots are offline and we keep them offline;
we don't keep them in safes because of the
fact that if there ever was a physical
attack that we couldn't protect the CAs
we could we could easily or fast and
more quickly zero out an HSM as
opposed to let's say go and get a
safe and try to break the media or
or bend the PCMCIA card to create the
mess to burn itself or something in a
sense of destroying the root, so
it's not overtaken, but again you
know that we take a lot of measures
and we're constantly - I want to say we're
constantly revamping those functions;
we're upping our crypto facilities;
we're obtaining higher levels of HIPS for crime
and things like that for our CAs and the HSMs
they reside on, but again, these are the
things; this is what we do; this is what
we spend our time and money putting
back into, to better protect our customers
and better protect the services we're
providing, because if you look out there
and again I'll digress for a second
and then I'll move on, but if you look at
the industry over the last three to five
years, the certificate itself is not
being attacked - that's pretty uniform
stuff; the CAB/F says it has to be;
what happens is it's the serviceability
of that CA, so depending
on how you're credentialing your customers
to come into your back-end and do
functions, and form and function
things with their certificates, that
becomes, you know, kind of the straw that
breaks the camel's back, and so what
happens is they go after the
serviceability of it and when a CA is
compromised from that perspective you
really start having to ask the hard
questions: is this really the CA I want to
be with, because they've been broken:
not necessarily at the certificate
level but at the level of
their bread and butter which is their
serviceability, and again, not to bad-mouth
another CA; this is just the state of
how things are and what happened, so I'm
not trying to change history;
the history is already there,
right, and I am not looking backwards, I am kind
of keeping us in a forward-looking projection,
but the bottom line is other CAs have been
been compromised and you really have to ask
that question because it's the serviceability
of the CAs, it's not just the product itself
and again, the product itself is very
straightforward: it's a certificate,
it has got to follow a uniform set of rules
by the community that we all agree upon
So again, anyway this is kind of
again, you get what you pay for
is kind of the way I believe it, OK? And
again, I like to say that is PKI as a service:
I heard from a customer tell me once;
I think that's an outstanding way to put
it in perspective, is it really is kind
of PKI as a service: you own it,
you manage it, but we maintain the
infrastructure and we watch the
industry, where the industry's going and
in some cases, and a lot of cases, we stay
proactive to where the industry's
going and we adapt accordingly and
that's why a lot of times you'll see
these changes sometimes every
two to three years,
three to four years
like recently because we see where the
industry's going, we see what's happening,
we're keeping an ear to to the track
constantly to make sure that again,
those changes are there that we start
adapting our customers, and at the same time
if customers are coming back to us
with feedback, whether that be
questions or concerns, we're taking it back
to the CAB/F and letting them know, look,
this is the direction we're seeing it going,
you know, can we adapt and things like that.
That's why you'll see product changes as
well, OK? So let's go ahead and move on
to the next slide; think we have been on this long
enough. So the situation's not much different
generally speaking. As some of you may
recall, our 1024/ 2048 migration as an
example. This was also a
process that created a term
of gray area we're in today where we still
accept 1024, but 2048 is ideal, right, so
we're kind of in that gray area now where you can
still kind of use SHA-1, we make it available,
but ideally we want you using SHA-256,
that's kind of where we're at today.
So while that again goes back to the
sunsetting methodology of doing things only
as fast as our slowest customer so to
speak, it also kind of makes
things a little convoluted, I guess, for
the customer: where really should I be?
Ideally you should be here is where we try
to project it, but if you have to go back
here you still have that cushion, but
again, if you ever look at our pages where
you can use SHA-1, it is in a very
limited capacity, it's only for a year;
we're not letting you modify end dates
or any kind of crazy stuff like that;
you're really on a small, or a short and narrow
path, because of course it's going away.
But at some point we did remove the 1024
allowances as a whole with any incoming
CSRs, right, so at some point you just
saw 1024 go away. You're going to see the
the same thing with SHA-1: at some point
SHA-1 is just going to go away this year:
you're just not going to see it there any
more, but the bottom line is are you ready?
That's really what it boils down to. Are
you ready for that change, because
if you're not, then it's really going to
come and kind of be a slap in the face,
and we don't want it to be
that for the customer.
We're trying to again buckle down and
make sure we're ready now, so that way
we're handling any "onesie twosie" things
that are happening, which we've done:
we've done special ceremonies, and again,
because this is quote-unquote stuff we had
done ourselves and we control, we can make
those adaptations, we can do it pretty easily.
Does it incur a cost? The reality is yes, but
we're not lying about it; we're not waiting
till the last minute and saying oh by the
way you owe us five grand for a ceremony;
we let you know in the beginning. I as a
systems engineer, who do pre-qualification,
I really try to deter customers from
doing special ceremonies; that's
kind of - without getting on a tangent
here, I really try to say look, can you
buckle down, can you get it done this way?
If we have to do a special ceremony we can,
but ideally it's got to be more of a
last resort type of thing because we
manually upload everything after that, and so
you know, again, managing that certificate
becomes a little different than what
you would do in a traditional issuance
as an example, and again I'll digress,
just giving you an example again. OK?
And again, other products under the trust services
umbrella will be following this soon enough,
right: as you see the key size has changed;
code signing key size has changed;
client PKI, their code signing size, I mean
their code signing client certificate key
sizes are starting to get longer as well,
so just because you're seeing an SSL does
not mean there's no ripple effect there;
there definitely is a ripple effect,
but a lot of the ripple effect
that you see from a Symantec perspective
we do it as a matter of good housekeeping;
we know eventually these
others, these things quote-unquote
are going to be affected, so a lot of
times we just start adapting them now
and getting them ready for those changes,
OK? And again, just like we were talking
about SHA-1 today, 1024, the key size was
never really broken. 768 was; key sizes
below that were: with the changes in
computing power they were broken, but
is 1024 breakable? From a theoretical
perspective yes, it's breakable.
So it's not a matter of if, it's a matter of
when, and so of course that's why we adapted.
Same thing with SHA-1: SHA-1 has
not broken yet, and that's the one thing
you'll probably hear me say throughout this
presentation more than a couple of times
is that look, SHA-1 is not broken,
SHA-1 is still working and it's out there.
But can it be broken? It's not a
matter of if, it's a matter of when.
At some point it probably will be broken.
The flaws that are there may be coming
faster and faster to the surface to be
broken because of the changes of
computing power, changes in technology and
the enterprise network, etc., and just
the accessibility of faster computers
these days, the accessibility of faster
processors and phones. Not that I want to tie
everything to computing power, but it
does kind of, the conversation
does kind of go circular, right, it does
kind of reside back to those areas. The things
that can get me in there faster are computers
and micro-computing power type things:
phones, whatever, tablets, whatever,
and apps are becoming more nimble and
more agile with those faster processors,
and of course more and more exploits
are out there as we start expanding the
breadth of network technology and
other things that reside in our network,
again, mobile computing against desktop
computing and things like that, right?
And again I keep digressing here but a
lot of this, a lot of areas that have
become more work for you as network
administrators and IT administrators
that you have to govern, right, and I'm sure
I'm probably getting a name in on that from
a lot but there is, and I hear this every
day when I'm working with customers,
every day I'm dealing with large
and hybrid enterprises that are just
now I got to adapt to this, oh by the way
I've got a point-of-sale device out there;
how the heck am I going to adapt that
root without spending money to get a
subcontractor to go out there and do this,
whether it be in a Taco Bell or Cabelas or
whatever, but again all these things as I as an
IT adminstrator I have to get a handle on,
right, and again this is where you start seeing
the security landscape adapt accordingly, OK?
But on the same note, you know, we
utilize the sunsetting methodology to
best service our customers. Again, we're
only as fast as our slowest customer,
as strong as our weakest customer
that may have a hard time
conjuring resources to get
this done: the reality is
it takes the village, whether you're
doing it to the public here and now
I have to go back to the planning phase to
my panel inside my company to get all
the teams crowd together to start going
and finding all their SSL certificates, but
again that's why that sunsetting methodology
is proving very successful for us
because we take all that into consideration
and we try to adapt the best we can,
but at the same time we also have to kind of
put a little pressure on you as a customer
and say look, you've got to get this moving;
what can we do to help you get there? Can we
talk to your vendors - which we've done - to
get them to say why aren't they adapting this
software and sometimes it's a version
change: that version change costs money,
so we we try to help the customer the
best we can is the bottom line, OK?
All certificates from a public CA that
are tied to a public root must comply
with the CAB/F baseline requirements,
right? That is - in our industry that's
kind of the gospel, that's kind of
what we're following, that's
what we have to go with moving forward
is that baseline requirement, and I
would say for those who are not familiar
with it, I would say get used to it, right?
Without sounding overly facetious,
because those baseline requirements?
That's becoming kind of the bottom
line of how we do things; that's becoming
the premise of how SSL operates in the
community. To give you an example: so you've
seen things like the 4-year function go
away on SSL certificates. That wasn't
Symantec waking up one day saying look
that's bad practice, let's get rid of it.
Did we wake up one day and think of that?
Yeah, absolutely, but we had to bring it up
to the CAB/F; we couldn't make that
adaptation without letting the CAB/F know
because again other CAs will probably want to
follow that at some point. Do browser vendors
agree with that? And so again there's
some level of uniformity that we
have to bring attention to the CAB/F,but
at the same time if customers are saying
something is not making a lot of sense
we also bring that up to the CAB/F and
again we have to base a lot of that
on revenue
and product size and things like that but
again customer feedback is always welcome;
it's not just that just doesn't
reside at Symantec and actually a lot of
times we take it to our
representative, we take it to the CAB/F
and we assure that there's agreement. We
have to talk to a third-party auditing teams
because they're the ones who come into
the CA at any time and some cases too
audit us, and we have to be sure that
if we are going to allow these kind of
exceptions and things like that, it
is not going to hurt us in an audit, because
if we get hurt in an audit, we technically
can't issue SSL certificates in some cases,
so there's a lot of ripple effect once again
that gets affected in the industry. OK?
So moving on.
In the hybrid enterprise model,
customers can manage their certificates under
the Symantec provisioning model; they can do this
with private or public trusted SSL certificates.
For all intents and purposes today
we're going to stay with public,
but we do have products in the private SSL
realm. Again that's for a separate conversation.
The private
model is especially interesting as you can
have access to multiple functions
while only paying for a product.
And again that kind of leads into our
enterprise product, but that's not what we're
talking about today. But yeah, this product
line we can focus on internal certificates
that contain illegitimate top-level
domains like a .org or .local
or something and again, I kind of keep
going back to it, but but there are -
or you doing it yourself is kind of the way
it goes, right: either I'm going to have a
third party do it for me or I'm going to
do it myself and I'm going to do it myself,
that is still considered private SSL
from a very general perspective, right,
because if you look at the industry you
really only have two trust models: public
and private trust; you don't have this gray
area "well I'm kind of trusted". Some CAs
Some CAs are like that: they're kind of
trusted in some but not trusted in others,
but really it's still considered public trust,
or really still becomes - the reality is, the
fortunate reality becomes a black and
white model. But private trust, you can
kind of do whatever you want, and
we've capitalized on some of that,
because we used to do that, way back in my
early days, without giving away age,
way back in my VeriSign days in the early
2000s, 2001 to be specific, we stopped
doing private SSL, because you have the
Microsofts, you have the OpenSSLs, you had
those other companies that could generate their
own roots and didn't really at that point
it wasn't worth paying a third party to
do it but then you get the care and
feeding of self-signed CAs and that's
really where the rubber meets the road;
that's where things start getting
very very expensive, very heavy,
especially private CAs aren't always a
revenue-generating environments so it
becomes harder to kind of budget that thing,
especially when you've got to re-provision,
you've got to retrain people, you've got to
update your key modules, you've got to update
HSMs, whatever: crypto updates can be very
expensive. I'll give you an example:
we updated our crypto facilities quite
a few years ago, give or take,
and we're talking in the very high
millions that it cost us, right, but again
that's at a public CA level. Take it up
to a private level where you still may be
mimicking some of the same things;
some of the things we do are not
that far off from what you do with a
self-signed model, but again the difference
with us in that aspect outside of being a public
CA is that we apply the same security model
to our private side as we do to our public
side. But again, let me get back on track,
but that's just kind of talking about, you
know, how the things that CAB/F
is going to be eliminating for best practices
can still be done in the private side,
and we do offer a product that doesn't
have to follow those CAB/F requirements,
but you can still get the lifecycle
management tools out of there as well.
Anyway, getting back on track:
I won't talk much more about the private, there's
a lot of areas I can go into but I'll just say
today let's look at it from a public
perspective. Anything you're going to do
that's not going to be accepted by the
public world, right? Baseline requirements,
again the kind of Gospel that we follow
as public CAs and browser vendors,
you're going to have to do it privately, and
so again what happens in the private realm?
Well, I'm only as trusted as far as my root
CA is propagated, so it's not inherent trust.
Public, the trust is inherent:
again that black and white model.
But private, you've got to control
that; you're going to do it
through a third party or you're going to
do it yourself, but again that CA
has got to get out there in some way
shape or form to eliminate that trust error
and with current browsers, right, or some
current client applications that might have
more logic in some cases, or less
logic, it it eliminates runaway processes,
or kind of that weird, quirky area.
It's very cryptic, but I think
from a user perspective
maybe I don't have the root
and my cert store and things like that, OK?
But again, getting on track here, from the
area of public recognition, you know, once
ICANN has awarded a domain to someone
or an entity, anyone already utilizing the
general top-level domain will have their
certificate revoked within
120 days of registration,
so that goes back a couple of steps
to what I was talking about with
illegitimate top-level domains: we used
to be able to do that with public SSL
or .local, and we had a few customers doing
that for years, but now again we get
back into that - I'm kind of going
circular in the conversation, so I'm
jumping in a lot of areas, but it
gets back now that you can't do that
with public trust anymore; it's going away; I
have to do it with private now,
so now the good thing is I got some kind of
leverage, right; I'm doing public or private here,
but where do I want my
private self-signed certificates from?
Do I want them from a third party
or do I do it myself? Again, a lot of stuff
happening based on that basic premise of
best practices in baseline requirements.
Again sorry for the confusion, for
muddying the waters a little bit there,
but jumping to the map there's
obviously a lot going on in these
timeframes of 2012, 2013, 2014, because now
- and again we're just doing a recap -
of those things that are the baseline
requirements, that gospel so to speak,
that's happening to the
Internet community, the SSL community
in particular, that customers at the end of the
day are left to do the work; they have to
follow it with because as public CAs we're
going to hard-line it and start setting
those up and make them
available for customers, OK?
So let's jump to the next slide.
So now, moving into 2015, we see
the changes in SSL certificate end validities
similar to the gTLD issue and the
non-FQDN issue, but at an earlier point
SSL certificates could utilize one to four
years; remember I talked about it a little
while ago that the four-year
just kind of went away,
and we put statements out there, and
email campaigns, but the bottom line
is it just went away. There wasn't
a whole lot of this is why we're
getting rid of it but we knew it was the
best practice. We've looked at some of
the sectors, industry sectors
where our customers operate:
financials as an example, who are really
tight on what they do with certificates;
they weren't exceeding three years,
three years was almost taboo
with some customers I spoke to, but
four years was just not happening and so
again we went and took that back to the
CAB/F and we reviewed all this as public CAs
and browser vendors once again, and four
years just kind of wasn't winning the vote,
so it went away, is basically
what happened, OK?
But the best practice is really no longer
than 39 months; we say 39 months
because you have that 90-day window to
renew, so 36 but inherently it's 39 months.
And again, along with the lifecycle
changes by October 1 2016
all certificates under public trust may contain
only an FQDN or fully qualified domain name
for the common name and the SAN values.
For those who aren't familiar with SAN,
it means subject alternative name.
Think of it as your driver's license
and you have multiple aliases on your
driver's license: that's essentially what
a Subject Alternative Name is. You may
hear a different reference like unified
communication. Unified communication
model and SAN tie together at a premise:
SAN is what's being used but unified
communication use is slightly different
because of applications. Microsoft is an
example, but again I don't say this as a
derogatory term, but in the sense that again
you know just how other vendors may use it.
But when we talk about fully
qualified domain names, that's all
that can be in your public trust
certificates: you can't have IP addresses;
you can't have short names or NetBIOS
names that have to follow that public trust
model, OK? And again, remember what
I said earlier: the baseline requirements
of what's acceptable in
the internet community.
So take another second to look at
that, and we'll jump down here.
OK. So, moving past the FQDN values for
public trusted SSL certificates:
we're not really completely migrating
to the SHA-1 deprecation yet,
but we're getting there, right, but
again, similar to the 1024-bit migration
from the prior year. So what I mean by
that again is kind of the same institute
of techniques and processes we're applying.
Did we learn our lesson from what
we've seen with the 1024 migration?
Absolutely. Some of our communication
models changed, but again kind of the
same set of processes, same steps,
almost the same path we're following,
because again it was something in a
certificate that was being changed; we
didn't necessarily have to go and
reinstitute the wheel, we could change out
a few spokes for lack of a better term.
We could re-sign some key pairs, but you'll
see our intermediates definitely changed:
they went from G3 to G4 or things like
that, again because those with
intermediate CAs they don't have
to be collected in the industry;
intermediate CAs are the public CAs' job to
distribute, and the customer who installs
the SSL certificate installs the
intermediate and then it gets handed out
during the handshake, so for
us, changing intermediate CAs
absolutely makes sense and
what you'll start noticing
is maybe you'll see a VeriSign root - once
again going back to the very beginning -
but you'll see Symantec
written all over the intermediate.
And once you're really having application
compatibility issues that's again
tom-ay-to, tom-ah-to: they're all under the
same ownership it's just now we're starting
to change things over to Symantec, and over
time, as roots get older and as we're
propagating new roots like we have been
recently, you'll start seeing Symantec show
up like on DSA, digital signature algorithm:
you'll start seeing Symantec's name on there
as opposed to VeriSign and things that, OK?
But again, any certificates
with SHA-1 under public trust
cannot expire post 1/1/2017.
We have a working list of customers
that we're currently working with.
Again, you know, I don't want to
make it sound kind of Gestapo-ish,
like we're chasing after them or anything
or nightsticking on the data centre door,
but we're actually working
very closely with them; you know,
again, it's that "what can we do for you;
how can we best service you in this area
to get you up to speed because we're
only as fast as you can adapt", but again,
some of this quote-unquote stuff we really
don't have a lot of choice, this is the
industry yelling at us, so we've got to
move you along, here we've got to get you
updated and again sometimes that's making
communication with vendors through
TSANet or directly to our contacts
that we have, or again doing what we can
to help the customer to get them you
know absolutely there, but it's always
that sunsetting methodology, OK?
With that let's move on.
So the security landscape is changing its
technology updates at a faster pace,
and for a lot of us in IT administration
we've been seeing this, obviously, right?
Refreshes are no longer four and five years;
sometimes they're two and three years;
in some cases depending on the device maybe
it's a year, like a mobile phone or something
but again because you're talking about
single core, dual core, even to some extent
quad-core and Atom-based processors, it's
extremely fast and extremely small and
also this device becomes a little
rocket in your hand, right, but again,
it's a very powerful little device, but those
refresh rates sometimes change because of
the adaptations of technology and
depending where that person resides,
whether it's field sales, whether they're
working in a knock somewhere, but they've
got to have really fast communication: again,
without getting on a long tangent on that
you may just see updates change at a
quicker pace, but as the leader in our space
we see seek to stay proactive and
work with partnering vendors to ensure
best-of-breed PKI practices, so again just
because it's dictated at the CAB/F
doesn't mean we're not already looking
ahead; in some cases we try to set the bar
in the way we do things and how we
adapt our security practices.
As an example: private and public root
architectures.
In some enterprises they may not be
looked at under the same looking glass.
From the Symantec perspective, because
we have such a broad customer base,
we treat our private and public
trust models exactly the same:
we apply the same amount of levels, the
same best-of-breed security practices there,
and again, because of course why would we
want to divvy that up and take any chances
when we can just kind of set one
baseline that's way up there
right, so to speak, that's really good
security, and again its all about you,
it's protecting you as a customer, not just
protecting our stuff: that all kind of goes
hand in hand, that quote-unquote stuff,
right, it's all that: it's protecting the
customers that's using that stuff, right?
As we said earlier with those CAs
you know, without saying names, that have
been infiltrated at one point or another,
maybe they've recouped from
that now, but why start the race
in second when you can start the race in
first and just maintain first is the way
I've looked at it, being a military guy. Why
would I want to start the race and fall
back to second and I'm not saving any wind that
way; I'll get to the front and stay there,
and that's what we've done as a leader,
and again, we treat our infrastructure
that way as well and our practices so it's
always kind of keep us first in that running,
but again, to do that, sometimes you've got
to spend more, you've got to do it yourself,
you don't rely on third-parties to do it
because now my customer is relying on me to
rely on my third party to stay proactive
and all that approach as well.
And if you take things like revocation,
where third parties have went down,
causing customer certificates
to not work at all,
again, that's bread-and-butter
stuff quote-unquote, right, we don't
want to take advantage, don't want
to mince words on that and say
oh, its OK here and there; that's never OK
for certificates not to work for a customer
and things like that, but again we recognize
these changes to be difficult for customers,
that's why we're doing the presentation
and other things and campaigns etc.,
but whether the complexity
of the enterprise network to
just being able to make contact with all
teams we apply the sunsetting methodology
again to provide our customers as much time
as possible to adapt to the industry changes,
and again those things aren't going away.
What gives us the flexibility
to make those adaptations to the existing rules
is the ownership of our infrastructures,
of our infrastructures, again I've kind
of just beat the drum a little bit
so I won't beat it too much farther, but
again we don't treat PKI as a commodity,
and I think that's the key to remember
like back in my day i worked for a large
company with a 3 in front of it, that
sold network interface cards before
there was the invention of the LAN on
motherboard or the LOM, and I remember
that we didn't treat network interface
cards as a commodity either,
I mean eventually we just kind
of fell into that because you
can integrate it anywhere and everywhere,
but we used our parallel tasking
technology and it really paid
to have that card. Was it more
Was it more expensive than your average
network interface card? Sure it was,
but the speed and the functionality of
what it did was vastly, just outdid the
other cards that were on the market,
but again, technology changes,
and things can - you know
micro-computing etc. but
again going back to that is that we
don't treat SSL that way and again I'm
trying to say SSL will eventually be integrated
in a chipset or anything; in some cases it is,
like vPro as an example, but we don't
treat SSL certificates as a commodity;
commodity, not the certificate itself,
because remember that's kind of uniform,
because industry all have to apply the
same set of rules, but it's the services
that give you that certificate that's where
the rubber meets the road, and that's
what we don't commoditize, and an example
of that would be off-the-shelf solutions
that are pre-built for you to use, so I
just plug it in and I'm doing revocation.
We don't do that. We build it
from the ground up; we take the F5s
we take the A10 Thunders; we take the Citrix
Netscalers and Cisco devices and the Junipers
and we put them in our environment and
we scale them and we structure them
in a way that best services throughput, but
also best services our security model as well
and again I'm just going to throw
some random terms out there
but again like I said we use third-party
products to construct our backend etc.
but really it's about the infrastructure
and the services it provides,
that's where that's again this is what we
do, right, and if we didn't do this well,
then we wouldn't be number one
in our spaces, and again it's kind of
just me beating my hands on my chest a little bit
but adaptation to a certificate nomenclature,
things like that those can be done
through ceremonies, again we can do it
pretty quick, almost two times a week in
some cases - manually, by the way - it's
because we own our infrastructures,
that's kind of what it all boils down to.
Where others say we just can't do that, give
us two weeks, we can do it fairly quickly,
sometimes we can even
do emergency ceremonies,
emergency ceremony is very
fast, and get that done, OK?
But on an additional note, Symantec is a
founding member and a large part of the CAB/F,
that is key to remember, and we're part of the
decision-making process. we're kind of the
panel leaders there but even if you're not
a panel leader it's public safety and
you have to follow those rules, so sometimes
when you're looking at CAs, that's the question
to ask, you know: where are you in that process?
Are you a follower or are you a leader?
Because that a lot of times tells you
where they're going, tells you you how much
of the bread and butter - how much money they're
putting back into that bread and butter
of what they do, and things like that.
And again I'm not trying to sell that or spiel
kind of more kind of putting it all in
perspective so there's money when you
start dealing with PKI there's lot of free-floating
data out there; a lot of stuff to grab at.
Where do I need PKI in my infrastructure, how am
I going to implement it and things like that.
The clock's ticking. Let's move us on.
But you should expect more
migration-type changes in the future as
Symantec and the CAB/F seek to make
the Internet a safer place for you. And
again not so much just for the enterprise,
but really at the end of the day is
kind of where the rubber meets the road
to bring that user back to the internet.
Remember back in the 2011 timeframe,
somewhat earlier, that one Christmas
year we kind of didn't have a lot of
online presence because of the recession,
all kinds of crazy stuff going on out there,
but we always look at that as keeping your
user, which inherently is you as our customer,
keeps them on the internet, keeps
them doing it because we're making it
a safer environment, right. I'm not
going to take my kids to the playground if
the chain link fence is run down, and
and there's a bunch of some kind of
shady characters hanging out there, but
if someone comes in and cleans that park up,
starts putting nice white nets on the
basketball hoops and sitting there and
cleaning the kids' playground, then yeah I'm
going to be kind of, you know, adept at bringing
my kids back there. That's kind of saying
we're treating the internet, I guess,
without making funny comparisons
or quirky or campy comparisons, but
we're keeping that play area clean,
and that's the internet, right, keeping
security there and making sure
it's sound and making sure the
users are doing their due dilligence,
paying for products and really putting
their money into your products,
again which which is kind of why we're
there, but but the bottom line is
you should expect more migration type change
in the future, as the security landscape
is changing a lot faster and you really
just want to be ready for what's happening,
and we're doing the best we can to
adapt to our customers as well.
That kind of brings us to the end of
that timeline and before we get into
this timeline let's let's do
another polling question as we
start to wind down here. Gimme one
second here. We're going to actually
talk about another another
question here in just a second.
OK so in this one lets talk about let's
talk about how are your locating all your
SHA-1 SSL certificates in your ecosystem, and
this is a pretty straightforward question,
but again, you know, are you
using an internal discovery tool
or using Nmap or some other fun stuff,
you know, are you using VA tools
that can do https capturing on the side or
do you have a third-party discovery tool;
once again, it could be you know
like a Qualys, it could be CIC or what have you.
Maybe not necessarily direct emphasis
but, you know, the secondary emphasis on
https capturing like an IPC60 or something.
Or you don't have a discovery tool;
there's other means of doing it or other
methods, or really I just don't know,
I'm not there yet. But bottom line,
let's take a second, just a couple of seconds
and answer that and when we do it
we're going to move on here, OK?
Actually let me jump back one slide: I really
didn't describe this one, but this is a nice
slide to look at because this is a very
very kind of in-your-face but simple
model of saying look this is what this
year the particular browsers are going to
be doing, right, if you look at Chrome, if
you look at your Firefoxes, you look at
your IEs, your Internet Explorers, even your
Spartans in some cases of what there was in 2010
they're going to start adapting
differently to how SSL operates.
And again not
being in favor of one of the other but
some cases like I said, you look at
the way SHA-1 is being utilized and these
are different dates whether it be through,
or starting January 1, or, you know, from
through May 31st 2016, you're going to start
seeing certain changes there; maybe
you'll get a security warning; maybe
you'll get something over the lock, but
they'll still let you do it, but eventually
if you work your way down to the right here
under the SHA-1 like with Chrome as an
example: with build 42 you're going to start
seeing a red X on that lock, right, if
it's still SHA-1, so what does that mean?
So that means if I have SHA-1
certificates out there I'm kind of
still at the mercy of the browser, right,
I'm still having to worry about how the
browser even though Symantec says it's
OK or another vendor does say look you can
still use SHA-1 for a little, we'll still
honor your quote-unquote stuff until
2016, but that doesn't mean the browser's
going to play fair in that way, the browser
may come back and say hey you know what, you're
using what's called obsolete cryptography;
it doesn't mean that it's bad, it
doesn't mean that is broken, but
you know, hey, it's not the latest and greatest
quote-unquote stuff that's available.
So what does that mean? it always
applies to two sides of a coin:
the internal and the external aspect of
things. Is it generating more calls internally?
Is it inherently, somewhere on paper, is
that costing me money as a company owner,
or as a division owner that has to decide
budgeting, those kind of things, right.
So again, we try to move as fast
as our slowest customers, but
from you as a customer perspective
that directly affects you,
does this affect revenues, the bottom line?
Does it affect that? And that sometimes will
propel how fast you get these adaptations
in there, but again, be ready:
this is stuff that's happening now. Chrome 39 is
already out there; if you allow Chrome as
part your baseline policy to be used in
your ecosystem, you should be expecting these
kinds of things to happen. And 2017, that's
coming up pretty fast, so you only want
to start getting ready for that if you haven't
been, OK. Take another second, go and look
at that, then we're going to jump down to the
number line and again we're kind of moving
a bit slow on time or we're losing time so I'm
going to hurry up and get us through this.
But let's talk quickly about the timeline
here. Really what I want to jump into is
I don't like to look too far back; I'm
kind of a forward-facing looking guy,
I try to stay positive in that
respect but let's look at 2015
Starting early 2015, Firefox
is already starting to show some
errors there, and of course Chrome
was already, but Firefox is jumping on board,
so what does that mean? That means not
necessarily CAB/F stuff quote-unquote
but it means the browsers kind of all follow
the same suit at some point, and again I don't
mean that derogatory, but but they all see
where the industry's going as well
and all these vendors are paying
attention to that stuff, right, and and as
you start clicking down to 2015/16/17,
you start seeing that they're all kind of
getting on that same path, right, at some
point the bottom line is that at some point
SHA-1 is just not going to look good
in your browser; may not even be accepted.
Take non-chaining certificates as an
example. Non-chaining means there's no
intermediate CA, there's SSL cert directly
to a root; you don't see that any more,
and if you do provide it with a self-signer
and you dump the root into the cert store,
if you try to connect over IE as an example,
IE is going to say something back to you
which rightly so: browsers
should be doing that.
Browsers are doing now what they should have
been doing five six seven eight years ago:
they're being more interactive
in the model, they're telling you
look, don't click OK to go, it takes a
click acknowledgement if you want to go
to that page because there's a reason
I'm not sending you there, that you should
be very concerned about that because of
phishing, because of infiltration,
because of sometimes somebody planting
an exploit and waiting four or five months
and then coming in there secretly
and starting taking information.
The federal government: it happens at the
highest levels of security, and again they're
kind of following that Google model:
everything's being done over SSL now,
and again I'm not capitalizing on what's going
and aim hits out over one or the other,
just that you start seeing the
similarities: they're getting on
the same path, which is creating
a bigger table at it, or a
bigger ripple effect to how all
operating systems and web interfaces
and other things are starting to adapt
to what's happening with cryptography,
right, and again we really
want to pay attention to that,
not because I work at Symantec
and that's who's on my paychecks, but it's
because it's going to affect you in some
shape or form if you've got even a minute
footprint on the internet, this stuff
affects you, right? This stuff - and not
affects you as my customers, but it
affects you as man I got to go walk in to
work every day and deal with this stuff; I
got to figure out an action plan
to get me adapted and make sure that
my customers are protected, right?
Let's jump on here, we're
going to move pretty quickly.
So let's talk about Symantec's responses
to what's happening out there.
Right, again, limiting the validity periods for
SHA-1. And again we're going to actually block them
at the end of this year, but if you have
certificates that expire in 2016 we'll honor them.
And again, we're going to stop issuing
after this year: 12/31/2015
Remember, "smoke em if you got em": if you need
to get your SHA-1 certs you'd better do it now,
better start doing it from here on out
throughout this year; my recommendation is
probably build somewhat of an action plan,
as being a leader, when I was young
jarhead in the Marines we used to think
you always start with the end result, work
your way back to the beginning and a good
leader will have already done that, worked their
way back and say OK, this is how I'm going to get
to that end result. If that hasn't been done
I'd probably start to recommend that
pretty heavily, right, because this stuff is
going away; this is industry; this is not
something again that Symantec
just decided to up and one day do, this
is something affecting everything
we do on the internet. And of course we
already have SHA-256 intermediates out there.
You get a SHA-256 cert today
it'll be off a SHA-256 intermediate;
the industry doesn't require that
SHA-1 root yet or the SHA-256 root,
excuse me, but we have the universal
root already out there, and of course
SHA-256 certificates will carry standard
validity periods: one, two, three years,
pretty much the same stuff there, right,
quote-unquote, nothing's changing
from that aspect, and of course
when you get into the hybrid enterprise
or when you start dealing with the
managed model you start looking at
private SSL, right, which is under the
managed PKI for SSL model,
but that's for those accounts only and I'll
digress: that's not really part of where we're
going from a product perspective, but those
are just letting you know, the things that we
do holistically to support that. So you
know what to do? You want to discover
and locate all those SHA-1 certificates,
whether you're using internal tools,
or CIC to manage PKI for SSL, but
again you want to start locating
all those SHA-1 certificates. You want to
create a migration plan, you want:
do I have hardware / software conflicts, am I
just going to have to update the stuff, right.
Some of this is probably for a lot of you just
common sense; stuff is going to fall into place,
but have we thought about that yet, have we
thought about potential compatibility issues.
Then we talked about certificates
expiring before January 1 2016, they're
going to be renewed with SHA-2; this is what's
going to happen. Or you might be able to still
get SHA-1 for a limited time, right,
again about a year, but
if you renew them now you're going
to get the SHA-1 still, but after
12/31/2015, there's no dice at that
point here, you have to go with SHA-2.
Are you ready for that? That's
really what it boils down to.
Have you installed the
correct SHA-2 intermediate?
So while it sounds kind of hokey, I tell
customers did you go to our installation pages?
I don't doubt you know how to put
it into, you know, to OpenSSL
or into your F5, but did you go
there and grab that CA-bundle file
that carries the SHA-2 intermediates, because
if you didn't, well, you've kind of got the
shotgun pointed at your foot at this point:
you're setting yourself up for failure and you're
going to set yourself for a long support call,
we're going to walk you through all this.
And sometimes just replacing the certs, if
it's like a java-based keystore and you
installed things non-systematically and you
have to go and make changes, that sometimes
can get very finicky, so you're setting
yourself up for a support call
and I tell customers: follow the instructions,
we put them out there for a reason:
it has nothing to do with the intelligence
of the server administrator, has everything
to do with doing things properly to make
sure that we facilitate all the proper
services to you. OK? And again, SHA-1
certificates expiring after 1 January 2016,
at any time I can replace
them: I'll get a SHA-2 certificate and
replacements are offered at no charge.
Always remember that
we offer replacements up the life
of a certificate at no charge, OK?
Some additional references: Am
I using SHA-1 certificates,
how do I replace my SHA-1 certs, how
do I replace my SHA-1 intermediate CA
you know again that's getting into
SHA-2, we have our links right there.
The links will be available, you can click on them
anytime and again after this we can always give
you a PDF version of the deck with
the hyperlinks as well, but whether it be
Symantec GeoTrust or RapidSSL or any of
the family of Symantec-owned CAs
we definitely have SHA-1 help pages there.
Well, they differ slightly, sure, but it's
all kind of the general area, right, it's
getting over the SHA-1 hump so to speak
And additional resources at this point, dealing
with getting a certificate signing request,
installation, how to manage SHA-1
deprecation, things like that, those are all
areas that we have under our knowledgebase
as well, so it's all public-viewable
information. And last but not
least let's talk, right. Call your sales
rep or your account manager, email
technical support someone in there,
to get the things that you need answered
to either myself or to the support team
and then I try to take the most objective
way that I can with customers,
but again getting you to the end result, OK?
And that wraps up my section.
So we're over time; I'm going to
look at a couple of questions here.
I'm just going to answer one;
I got about a minute 55 here.
So let's do the the first questions:
I've been purchasing SSL certs for
our websites for the last six years.
Are they already SHA-2 compliant for my
Tomcat key stores? The answer would be yes.
But I would go back and say check on your
version of Tomcat. Does Tomcat support SHA-256?
If it's a third party that's OEMed it and
owns it then you've got some support
or you're going to be
checking forms, but
absolutely make sure that web
application truly supports it and again
we allow grace periods when you install
certificate for you can revoke it you
can still get your money back on it so I
would say absolutely if you can test it
do that definitely, OK? And it says do my
cert expires in early 2016 can I upgrade my
cert to SHA-2 now? I would imagine they
meant at no cost - and how? You would
replace it, and if you replace your certificate
throughout the life of the certificate
you never get charged for it, the new key
pairs will come out with the original or
the new public key will come out with the
original and validity and of course
when you replace it if it goes past
let's say the 2017 you will automatically
get SHA-2, in some cases using Symantec trust
centre, whether it be enterprise or not,
its going to be automatically defaulted
to SHA-256. So absolutely you can adapt.
Lots of other questions in here. I'm
going to answer all of you,
and again, I usually get a
spreadsheet and I work it and I
will answer every question I didn't respond
today but for the sake that we're over
I'm going to end the presentation here
and I want to thank you for your time today,
thank you for joining, and we look
forward to doing upcoming presentations for you.
There is an area here that you
can grade the presentation and grade my
ability to give a presentation I ask
that you do that.
Feedback is always accepted and
we ask that you have a great day.
Thank you for your time.