Loading ...
Sorry, an error occurred while loading the content.
 

SSL

Expand Messages
  • Dave Pawson
    I ve implemented a RESTful connection between two endpoints. One end is c# the other java (restlets). Our security people have now dictated that is should use
    Message 1 of 17 , May 31, 2006
      I've implemented a RESTful connection between two
      endpoints. One end is c# the other java (restlets).

      Our security people have now dictated that is should use
      SSL.

      I'm suffering getting my head round the basics
      of SSL.
      The basics of a POST, with encrypted content
      are clear, but applying it to our sequence of PUT GET DELETE
      are distinctly muddy.

      I think SSL3 http://wp.netscape.com/eng/ssl3/draft302.txt
      is current.

      Anyone know of a reasonably clear intro
      to SSL that I might be able to apply please.

      TIA
      --
      Dave Pawson
      XSLT XSL-FO FAQ.
      http://www.dpawson.co.uk
    • Chris Burdess
      ... Surely they just mean HTTPS? -- 犬 Chris Burdess They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety. -
      Message 2 of 17 , May 31, 2006
        Dave Pawson wrote:
        > I've implemented a RESTful connection between two
        > endpoints. One end is c# the other java (restlets).
        >
        > Our security people have now dictated that is should use
        > SSL.
        >
        > I'm suffering getting my head round the basics
        > of SSL.
        > The basics of a POST, with encrypted content
        > are clear, but applying it to our sequence of PUT GET DELETE
        > are distinctly muddy.
        >
        > I think SSL3 http://wp.netscape.com/eng/ssl3/draft302.txt
        > is current.
        >
        > Anyone know of a reasonably clear intro
        > to SSL that I might be able to apply please.

        Surely they just mean HTTPS?
        --
        犬 Chris Burdess
        "They that can give up essential liberty to obtain a little safety
        deserve neither liberty nor safety." - Benjamin Franklin
      • Dave Pawson
        ... Not wishing to argue about something I know little about, yes Chris (I think so). I believe(d?) that https == the introduction of ssl into the stack?
        Message 3 of 17 , May 31, 2006
          On 31/05/06, Chris Burdess <dog@...> wrote:
          > Dave Pawson wrote:
          > > I've implemented a RESTful connection between two
          > > endpoints. One end is c# the other java (restlets).
          > >
          > > Our security people have now dictated that is should use
          > > SSL.
          > >
          > > I'm suffering getting my head round the basics
          > > of SSL.
          > > The basics of a POST, with encrypted content
          > > are clear, but applying it to our sequence of PUT GET DELETE
          > > are distinctly muddy.
          > >
          > > I think SSL3 http://wp.netscape.com/eng/ssl3/draft302.txt
          > > is current.
          > >
          > > Anyone know of a reasonably clear intro
          > > to SSL that I might be able to apply please.
          >
          > Surely they just mean HTTPS?

          Not wishing to argue about something I know little about, yes Chris
          (I think so).
          I believe(d?) that https == the introduction of ssl into the stack?

          regards

          --
          Dave Pawson
          XSLT XSL-FO FAQ.
          http://www.dpawson.co.uk
        • Chris Burdess
          ... Into the protocol stack, yes. But it doesn t affect your REST design in any way. You re still doing exactly the same GET, PUT etc with URLs, it s just that
          Message 4 of 17 , May 31, 2006
            Dave Pawson wrote:
            > On 31/05/06, Chris Burdess <dog@...> wrote:
            >> Dave Pawson wrote:
            >> > I've implemented a RESTful connection between two
            >> > endpoints. One end is c# the other java (restlets).
            >> >
            >> > Our security people have now dictated that is should use
            >> > SSL.
            >> >
            >> > I'm suffering getting my head round the basics
            >> > of SSL.
            >> > The basics of a POST, with encrypted content
            >> > are clear, but applying it to our sequence of PUT GET DELETE
            >> > are distinctly muddy.
            >> >
            >> > I think SSL3 http://wp.netscape.com/eng/ssl3/draft302.txt
            >> > is current.
            >> >
            >> > Anyone know of a reasonably clear intro
            >> > to SSL that I might be able to apply please.
            >>
            >> Surely they just mean HTTPS?
            >
            > Not wishing to argue about something I know little about, yes Chris
            > (I think so).
            > I believe(d?) that https == the introduction of ssl into the stack?

            Into the protocol stack, yes. But it doesn't affect your REST design
            in any way. You're still doing exactly the same GET, PUT etc with
            URLs, it's just that those URLs now start with https: instead of http:
            --
            犬 Chris Burdess
            "They that can give up essential liberty to obtain a little safety
            deserve neither liberty nor safety." - Benjamin Franklin
          • Nic James Ferrier
            ... Yes they mean that. I think you should not be worried. SSL/TLS are at the transport level. They don t affect application semantics unless you re talking
            Message 5 of 17 , May 31, 2006
              "Dave Pawson" <dave.pawson@...> writes:

              > On 31/05/06, Chris Burdess <dog@...> wrote:
              >> Dave Pawson wrote:
              >> > I've implemented a RESTful connection between two
              >> > endpoints. One end is c# the other java (restlets).
              >> >
              >> > Our security people have now dictated that is should use
              >> > SSL.
              >> >
              >> > I'm suffering getting my head round the basics
              >> > of SSL.
              >> > The basics of a POST, with encrypted content
              >> > are clear, but applying it to our sequence of PUT GET DELETE
              >> > are distinctly muddy.
              >> >
              >> > I think SSL3 http://wp.netscape.com/eng/ssl3/draft302.txt
              >> > is current.
              >> >
              >> > Anyone know of a reasonably clear intro
              >> > to SSL that I might be able to apply please.
              >>
              >> Surely they just mean HTTPS?
              >
              > Not wishing to argue about something I know little about, yes Chris
              > (I think so).
              > I believe(d?) that https == the introduction of ssl into the stack?

              Yes they mean that.

              I think you should not be worried. SSL/TLS are at the transport
              level. They don't affect application semantics unless you're talking
              about authenticating with client certificates.


              In essence, SSL secures TCP and you run HTTP over the top of it. The
              HTTPS simply allows for the connection to be made to well known
              ports. The HTTP is exactly the same.

              Note that it is actually possible to use HTTP over SSL; ie: SSL
              over port 80. There is a transport layer negotiation
              protocol which allows both endpoints to decide on encrypting the HTTP
              traffic. This is the _right_ way to do transport layer encryption
              because it involves no new uris.

              Unfortunately it isn't widely implemented.



              --
              Nic Ferrier
              http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
            • Dave Pawson
              ... If I don t code it, I can t see it happening. That s my problem I guess. ... That makes sense with what I ve read. ... I m nowhere near that Chris. I don t
              Message 6 of 17 , May 31, 2006
                On 31/05/06, Nic James Ferrier <nferrier@...> wrote:

                > I think you should not be worried. SSL/TLS are at the transport
                > level. They don't affect application semantics unless you're talking
                > about authenticating with client certificates.

                If I don't code it, I can't see it happening.
                That's my problem I guess.

                >
                >
                > In essence, SSL secures TCP and you run HTTP over the top of it. The
                > HTTPS simply allows for the connection to be made to well known
                > ports. The HTTP is exactly the same.

                That makes sense with what I've read.


                >
                > Note that it is actually possible to use HTTP over SSL; ie: SSL
                > over port 80. There is a transport layer negotiation
                > protocol which allows both endpoints to decide on encrypting the HTTP
                > traffic. This is the _right_ way to do transport layer encryption
                > because it involves no new uris.
                >
                > Unfortunately it isn't widely implemented.

                I'm nowhere near that Chris.
                I don't yet comprehend how it all glues together
                and what layers do what.


                regards


                --
                Dave Pawson
                XSLT XSL-FO FAQ.
                http://www.dpawson.co.uk
              • Nic James Ferrier
                ... Ah right. You do have to recode both ends. Languages usually have a separate api for connecting to SSL/TLS services. Java has HTTPSUrlConnection for
                Message 7 of 17 , May 31, 2006
                  "Dave Pawson" <dave.pawson@...> writes:

                  > On 31/05/06, Nic James Ferrier <nferrier@...> wrote:
                  >
                  >> I think you should not be worried. SSL/TLS are at the transport
                  >> level. They don't affect application semantics unless you're talking
                  >> about authenticating with client certificates.
                  >
                  > If I don't code it, I can't see it happening.
                  > That's my problem I guess.

                  Ah right.

                  You do have to recode both ends. Languages usually have a separate api
                  for connecting to SSL/TLS services. Java has HTTPSUrlConnection for
                  example.

                  Usually the SSL/TLS versions are just copies of the normal HTTP versions
                  and just as simple to use. On the server side you have to install a
                  certificate but there are detailed instructions for doing that in most
                  languages I've used SSL/TLS from.


                  >> Note that it is actually possible to use HTTP over SSL; ie: SSL
                  >> over port 80. There is a transport layer negotiation
                  >> protocol which allows both endpoints to decide on encrypting the HTTP
                  >> traffic. This is the _right_ way to do transport layer encryption
                  >> because it involves no new uris.
                  >>
                  >> Unfortunately it isn't widely implemented.
                  >
                  > I'm nowhere near that Chris.

                  /8->

                  Last time I looked I wasn't Chris.

                  But we did both used to live in London.


                  > I don't yet comprehend how it all glues together
                  > and what layers do what.

                  You just have to code the SSL/TLS equivalents of your HTTP client and
                  server.



                  Or you could always hire someone (I'm available; nudge nudge wink
                  wink).

                  --
                  Nic Ferrier
                  http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
                • Andrew S. Townley
                  Hi Dave, ... Not really to take a job away from Nic (besides, you shouldn t be hiring him to do just the SSL implementation part anyway... :), but here s a
                  Message 8 of 17 , May 31, 2006
                    Hi Dave,

                    On Wed, 2006-05-31 at 11:36, Nic James Ferrier wrote:
                    > "Dave Pawson" <dave.pawson@...> writes:
                    >
                    > > On 31/05/06, Nic James Ferrier <nferrier@...> wrote:
                    > >
                    > >> I think you should not be worried. SSL/TLS are at the transport
                    > >> level. They don't affect application semantics unless you're talking
                    > >> about authenticating with client certificates.
                    > >
                    > > If I don't code it, I can't see it happening.
                    > > That's my problem I guess.
                    >
                    > Ah right.
                    >
                    > You do have to recode both ends. Languages usually have a separate api
                    > for connecting to SSL/TLS services. Java has HTTPSUrlConnection for
                    > example.
                    >
                    > Usually the SSL/TLS versions are just copies of the normal HTTP versions
                    > and just as simple to use. On the server side you have to install a
                    > certificate but there are detailed instructions for doing that in most
                    > languages I've used SSL/TLS from.

                    Not really to take a job away from Nic (besides, you shouldn't be hiring
                    him to do just the SSL implementation part anyway... :), but here's a
                    working example that will do both 2-way SSL authentication and regular
                    HTTP requests to the same service in C#. Feel free to use the code.

                    http://sdec.reach.ie/rigs/rig0007/code/client/dotnet/rrmtp-client.cs

                    As Nic said, both ends will have to be updated, and, depending on the
                    complexity of your production environment infrastructure, your server
                    implementation may need to do SSL/HTTPS during development and not in
                    production because a hardware accelerator may be used for SSL
                    termination. It just depends.

                    Hope this helps,

                    ast
                    ***************************************************************************************************
                    The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
                    ***************************************************************************************************
                  • Dave Pawson
                    ... Many thanks Andrew. As it happens, the server side is C# so that s an ideal starting point. ... It does indeed. The client side is in Java, so I m on
                    Message 9 of 17 , May 31, 2006
                      On 31/05/06, Andrew S. Townley <andrew.townley@...> wrote:

                      > Not really to take a job away from Nic (besides, you shouldn't be hiring
                      > him to do just the SSL implementation part anyway... :), but here's a
                      > working example that will do both 2-way SSL authentication and regular
                      > HTTP requests to the same service in C#. Feel free to use the code.

                      Many thanks Andrew.
                      As it happens, the 'server' side is C# so that's an ideal starting point.



                      > As Nic said, both ends will have to be updated, and, depending on the
                      > complexity of your production environment infrastructure, your server
                      > implementation may need to do SSL/HTTPS during development and not in
                      > production because a hardware accelerator may be used for SSL
                      > termination. It just depends.

                      It does indeed.

                      The client side is in Java, so I'm on firmer ground with JSSE.

                      Many thanks.




                      --
                      Dave Pawson
                      XSLT XSL-FO FAQ.
                      http://www.dpawson.co.uk
                    • Andrew S. Townley
                      No worries. Glad I could help. BTW, if you (or anyone else) notice any bone-headed mistakes, just let me know. ast ...
                      Message 10 of 17 , May 31, 2006
                        No worries. Glad I could help.

                        BTW, if you (or anyone else) notice any bone-headed mistakes, just let
                        me know.

                        ast

                        On Wed, 2006-05-31 at 12:17, Dave Pawson wrote:
                        > On 31/05/06, Andrew S. Townley <andrew.townley@...> wrote:
                        >
                        > > Not really to take a job away from Nic (besides, you shouldn't be hiring
                        > > him to do just the SSL implementation part anyway... :), but here's a
                        > > working example that will do both 2-way SSL authentication and regular
                        > > HTTP requests to the same service in C#. Feel free to use the code.
                        >
                        > Many thanks Andrew.
                        > As it happens, the 'server' side is C# so that's an ideal starting point.
                        >
                        >
                        >
                        > > As Nic said, both ends will have to be updated, and, depending on the
                        > > complexity of your production environment infrastructure, your server
                        > > implementation may need to do SSL/HTTPS during development and not in
                        > > production because a hardware accelerator may be used for SSL
                        > > termination. It just depends.
                        >
                        > It does indeed.
                        >
                        > The client side is in Java, so I'm on firmer ground with JSSE.
                        >
                        > Many thanks.
                        >
                        >
                        >
                        ***************************************************************************************************
                        The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
                        ***************************************************************************************************
                      • Chris Burdess
                        ... There are several possibilities: 1. the client already has the certificate by some out-of-process means (it s set up statically as far as the application
                        Message 11 of 17 , May 31, 2006
                          Dave Pawson wrote:
                          > On 31/05/06, Chris Burdess <dog@...> wrote:
                          >> Into the protocol stack, yes. But it doesn't affect your REST design
                          >> in any way. You're still doing exactly the same GET, PUT etc with
                          >> URLs, it's just that those URLs now start with https: instead of
                          >> http:
                          >
                          > Too simple IMHO?
                          > How does the recipient get the certificate?
                          > etc etc
                          > That's what I'm missing.

                          There are several possibilities:
                          1. the client already has the certificate by some out-of-process
                          means (it's set up statically as far as the application is concerned)
                          2. the client has a means of presenting the certificate to an
                          authorising entity such as an end user or heuristic for trust
                          authorisation
                          3. the client decides the trust the certificate implicitly anyway

                          > At a high level I guess the overall view doesn't change
                          > but the code must change.
                          >
                          > I'm looking for an explanation of what changes.

                          In each case:
                          1. the client has a backend store of trusted certificates used by the
                          HTTP connection mechanism
                          2. the client has a configured trust authorisation interface
                          3. the client accepts the certificate

                          For 3, see e.g. http://javaalmanac.com/egs/javax.net.ssl/TrustAll.html
                          --
                          犬 Chris Burdess
                          "They that can give up essential liberty to obtain a little safety
                          deserve neither liberty nor safety." - Benjamin Franklin
                        • Dave Pawson
                          ... That would work for us. It s currently a one to one. We could set up the cert and check it by phone as a one off, then add it to the client keystore. ... I
                          Message 12 of 17 , May 31, 2006
                            On 31/05/06, Chris Burdess <dog@...> wrote:

                            > > How does the recipient get the certificate?
                            > > etc etc
                            > > That's what I'm missing.
                            >
                            > There are several possibilities:
                            > 1. the client already has the certificate by some out-of-process
                            > means (it's set up statically as far as the application is concerned)
                            > 2. the client has a means of presenting the certificate to an
                            > authorising entity such as an end user or heuristic for trust
                            > authorisation
                            > 3. the client decides the trust the certificate implicitly anyway

                            That would work for us. It's currently a one to one.
                            We could set up the cert and check it by phone as a one off,
                            then add it to the client keystore.



                            >
                            > > At a high level I guess the overall view doesn't change
                            > > but the code must change.
                            > >
                            > > I'm looking for an explanation of what changes.
                            >
                            > In each case:
                            > 1. the client has a backend store of trusted certificates used by the
                            > HTTP connection mechanism
                            > 2. the client has a configured trust authorisation interface
                            I don't understand this one Chris?



                            > 3. the client accepts the certificate

                            Then uses it to PUT content to the server I guess.
                            Makes sense.
                            Thanks

                            >
                            > For 3, see e.g. http://javaalmanac.com/egs/javax.net.ssl/TrustAll.html

                            Thanks again Chris.





                            --
                            Dave Pawson
                            XSLT XSL-FO FAQ.
                            http://www.dpawson.co.uk
                          • Chris Burdess
                            ... Meaning, there is a callback handler installed such that when the client asks the question do we trust this certificate? , someone is there to answer yes
                            Message 13 of 17 , May 31, 2006
                              Dave Pawson wrote:
                              > On 31/05/06, Chris Burdess <dog@...> wrote:
                              >> > How does the recipient get the certificate?
                              >> > etc etc
                              >> > That's what I'm missing.
                              >>
                              >> There are several possibilities:
                              >> 1. the client already has the certificate by some out-of-process
                              >> means (it's set up statically as far as the application is concerned)
                              >> 2. the client has a means of presenting the certificate to an
                              >> authorising entity such as an end user or heuristic for trust
                              >> authorisation
                              >> 3. the client decides the trust the certificate implicitly anyway
                              >
                              > That would work for us. It's currently a one to one.
                              > We could set up the cert and check it by phone as a one off,
                              > then add it to the client keystore.
                              >
                              >> > At a high level I guess the overall view doesn't change
                              >> > but the code must change.
                              >> >
                              >> > I'm looking for an explanation of what changes.
                              >>
                              >> In each case:
                              >> 1. the client has a backend store of trusted certificates used by the
                              >> HTTP connection mechanism
                              >> 2. the client has a configured trust authorisation interface
                              > I don't understand this one Chris?

                              Meaning, there is a callback handler installed such that when the
                              client asks the question "do we trust this certificate?", someone is
                              there to answer yes or no, whether this is done by a GUI dialog,
                              voice interaction, a Bayesian network or whatever.

                              >> 3. the client accepts the certificate
                              >
                              > Then uses it to PUT content to the server I guess.
                              > Makes sense.

                              It doesn't use it to PUT content, it just uses it to decide whether
                              it trusts the server (if not, it aborts).

                              You (or your security people) may be wanting to do HTTPS client
                              authentication as well. (Maybe that's the point?) In that case, the
                              server must have a store of valid client certificates and will refuse
                              requests unless the client provides a certificate in this store.

                              In all these cases it's simply a transport-level detail, like HTTP
                              authentication. Your application code shouldn't need to change
                              providing it uses an API at a sufficiently high level (e.g.
                              java.net.URL, Apache HTTP client, GNU inetlib). It just needs to be
                              configured in a certain way during deployment.
                              --
                              犬 Chris Burdess
                              "They that can give up essential liberty to obtain a little safety
                              deserve neither liberty nor safety." - Benjamin Franklin
                            • Dave Pawson
                              ... We are in a situation where the setup is long term . I.e few clients, with the certificates manually validated. Since the trust required is that the
                              Message 14 of 17 , May 31, 2006
                                On 31/05/06, Chris Burdess <dog@...> wrote:

                                > >> 2. the client has a configured trust authorisation interface
                                > > I don't understand this one Chris?
                                >
                                > Meaning, there is a callback handler installed such that when the
                                > client asks the question "do we trust this certificate?", someone is
                                > there to answer yes or no, whether this is done by a GUI dialog,
                                > voice interaction, a Bayesian network or whatever.

                                We are in a situation where the setup is 'long term'.
                                I.e few clients, with the certificates manually validated.
                                Since the trust required is that the server trusts the PUTting
                                client I don't *think* this applies to our case.


                                >
                                > >> 3. the client accepts the certificate
                                > >
                                > > Then uses it to PUT content to the server I guess.
                                > > Makes sense.
                                >
                                > It doesn't use it to PUT content, it just uses it to decide whether
                                > it trusts the server (if not, it aborts).

                                OK. Thanks. I was too early!

                                >
                                > You (or your security people) may be wanting to do HTTPS client
                                > authentication as well. (Maybe that's the point?) In that case, the
                                > server must have a store of valid client certificates and will refuse
                                > requests unless the client provides a certificate in this store.

                                Yes, we will want to check that the client is authorised.
                                <unsure>
                                We (server) will hold public/private key pairs.
                                We'll issue a public key | certificate to clients who will use it
                                to PUT data to our server. </unsure>

                                Does that make sense Chris?

                                >
                                > In all these cases it's simply a transport-level detail, like HTTP
                                > authentication. Your application code shouldn't need to change
                                > providing it uses an API at a sufficiently high level (e.g.
                                > java.net.URL, Apache HTTP client, GNU inetlib). It just needs to be
                                > configured in a certain way during deployment.

                                That's what I'm hoping for.


                                regards


                                --
                                Dave Pawson
                                XSLT XSL-FO FAQ.
                                http://www.dpawson.co.uk
                              • Chris Burdess
                                ... Right. You want 1. (Or 3, it doesn t actually matter at the client end.) ... Pretty much Each client should have a (unique) certificate and ensure that the
                                Message 15 of 17 , May 31, 2006
                                  Dave Pawson wrote:
                                  > On 31/05/06, Chris Burdess <dog@...> wrote:
                                  >> >> 2. the client has a configured trust authorisation interface
                                  >> > I don't understand this one Chris?
                                  >>
                                  >> Meaning, there is a callback handler installed such that when the
                                  >> client asks the question "do we trust this certificate?", someone is
                                  >> there to answer yes or no, whether this is done by a GUI dialog,
                                  >> voice interaction, a Bayesian network or whatever.
                                  >
                                  > We are in a situation where the setup is 'long term'.
                                  > I.e few clients, with the certificates manually validated.
                                  > Since the trust required is that the server trusts the PUTting
                                  > client I don't *think* this applies to our case.

                                  Right. You want 1. (Or 3, it doesn't actually matter at the client end.)

                                  >> You (or your security people) may be wanting to do HTTPS client
                                  >> authentication as well. (Maybe that's the point?) In that case, the
                                  >> server must have a store of valid client certificates and will refuse
                                  >> requests unless the client provides a certificate in this store.
                                  >
                                  > Yes, we will want to check that the client is authorised.
                                  > <unsure>
                                  > We (server) will hold public/private key pairs.
                                  > We'll issue a public key | certificate to clients who will use it
                                  > to PUT data to our server. </unsure>
                                  >
                                  > Does that make sense Chris?

                                  Pretty much

                                  Each client should have a (unique) certificate and ensure that the
                                  server has a copy in its truststore. Then it is the job of the server
                                  to authenticate the client based on its certificate. It is configured
                                  to authenticate requests with any method except e.g. (GET HEAD
                                  PROPFIND OPTIONS REPORT).

                                  An example Apache configuration (not tested):

                                  <Location /secure>
                                  SSLVerifyClient none
                                  SSLCACertificateFile conf/ssl.crt/ca.crt
                                  <LimitExcept GET HEAD PROPFIND OPTIONS REPORT>
                                  SSLVerifyClient require
                                  SSLVerifyDepth 1
                                  </LimitExcept>
                                  </Location>
                                  --
                                  犬 Chris Burdess
                                  "They that can give up essential liberty to obtain a little safety
                                  deserve neither liberty nor safety." - Benjamin Franklin
                                • Jon Hanna
                                  ... It does have one effect, which is that in general caches will not be able to cache GET responses.
                                  Message 16 of 17 , May 31, 2006
                                    Chris Burdess wrote:
                                    > Into the protocol stack, yes. But it doesn't affect your REST design in
                                    > any way. You're still doing exactly the same GET, PUT etc with URLs,
                                    > it's just that those URLs now start with https: instead of http:

                                    It does have one effect, which is that in general caches will not be
                                    able to cache GET responses.
                                  • Dave Pawson
                                    ... Any particular reason why one of the verbs should be excepted? E.g. I *think* I d want to authenticate the GET (even though there s nothing secure in a
                                    Message 17 of 17 , May 31, 2006
                                      On 31/05/06, Chris Burdess <dog@...> wrote:


                                      > Each client should have a (unique) certificate and ensure that the
                                      > server has a copy in its truststore. Then it is the job of the server
                                      > to authenticate the client based on its certificate. It is configured
                                      > to authenticate requests with any method except e.g. (GET HEAD
                                      > PROPFIND OPTIONS REPORT).
                                      Any particular reason why one of the verbs should be excepted?
                                      E.g. I *think* I'd want to authenticate the GET (even though
                                      there's nothing secure in a process report)



                                      >
                                      > An example Apache configuration (not tested):

                                      If only :-)

                                      The server is M$ based.
                                      (The clients are Java based)

                                      regards



                                      --
                                      Dave Pawson
                                      XSLT XSL-FO FAQ.
                                      http://www.dpawson.co.uk
                                    Your message has been successfully submitted and would be delivered to recipients shortly.