7 ms·

On Mozilla's forced SSL

46 points by joepie91_ 11y ago

diafygi 11y ago
There's one solution that the author didn't cover: Start treating self-signed certs as unencrypted. Then, deprecate http support over a multi-year phase out. That way, website owners who want to keep their status quo, can just add a self signed cert and their users will be none the wiser. For https there are two major objectives. 1) Prevent MITM attacks. 2) Prevent snooping from passive monitoring. Self-signed certs can prevent #2, which the IETF has adopted as a Best Current Practice (https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc7258). I'm much more in favor of trying to at least do one of the two objectives of https, rather than refusing to do anything until we are able to do both objectives. Here's a proposed way of phasing this plan in over time: 1. Mid-2015: Start treating self signed certificates as unencrypted connections (i.e. stop showing a warning, but the UI would just show the globe icon, not the lock icon). This would allow website owners to choose to block passive surveillance without causing any cost to them or any problems for their users. 2. Late-2015: Switch the globe icon for http sites to a gray unlocked lock. The self signed certs would still be the globe icon. The would incentivize website owners to at least start blocking passive surveillance if they want to keep the same user experience as previous. Also, this new icon wouldn't be loud or intrusive to the user. 3. Late-2016: Change the unlocked icon for http sites to a yellow icon. Hopefully, by the end of 2016, Let's Encrypt has taken off and has a lot of frameworks like wordpress including tutorials on how to use it. This increased uptake of free authenticated https, plus the ability to still use self-signed certs for unauthenticated https (remember, this still blocks passive adversaries), would allow website owners enough alternative options to start switching to https. The yellow icon would push most over the edge. 4. Late-2017: Switch the unlocked icon for http to red. After a year of yellow, most websites should already have switched to https (authenticated or self-signed), so now it's time to drive the nail in the coffin and kill http on any production site with a red icon. 5. Late-2018: Show a warning for http sites. This experience would be similar to the self-signed cert experience now, where users have to manually choose to continue. Developers building websites would still be able to choose to continue to load their dev sites, but no production website would in their right mind choose to use http only. Here's two relevant Bugzilla bugs: Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 https://bugzilla.mozilla.org/show_bug.cgi?id=431386 Switch generic icon to negative feedback for non-https sites: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
- ajanuary 11y ago
  Won't treating self-signed certificates as not-errors make 1 (prevent MITM attacks) worse though? You could then MITM an https site, serve up a self-signed cert, and anyone but the most observant users won't notice that something that used to be secure https now isn't. It isn't about refusing to do anything but both at once, it's that doing only one of them makes the other worse.
  - api 11y ago
    No, the idea would be that http becomes https with a self-signed cert. It shows as 'not protected' the way http does now to the user. It only turns green or gets the key box when it's a signed cert.
    - ajanuary 11y ago
      Very few people are going to notice that something that used to be green now isn't. In an attempt to increase security against passive monitoring (a laudable aim) this scheme heavily neuters https' ability to increase security against MITM attacks.
      - oconnore 11y ago
        You are describing a downgrade attack, which is addressed by HSTS, not TLS.
        ajanuary 11y ago
        HSTS is designed to protect against downgrading from HTTPS to HTTP. Best I can tell, it doesn't protect against downgrading from an HTTPS with a validated certificate chain to HTTPS without a validated certificate chain. To do that, you would need something like certificate pinning. Once there is a widely deployed mechanism for detecting when a certificate has erroneously changed it would be more feasible to stop treating self-signed certificates as errors.
simonhamp 11y ago
"problems that absolutely need solving _before_ a forced global deployment of TLS can happen" I'm all for this switch to SSL. But there's no way Mozilla's announcement will effect global deployment of TLS... not with 11.7% market share (NetMarketShare.com, https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0 https://www.netmarketshare.com/browser-market-share.aspx?qpr...). The realist in me says this will just frustrate developers as staunch advocates of Firefox pester for working services while higher-ups refuse to justify the cost to suit a possible minority userbase. These users being forced to either switch browser or move service provider.
- kazazes 11y ago
  Chromium/Chrome have already proposed a step in the same direction, pushing your market share figure up to 37.4%. [1] [1] https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...
  - mbrubeck 11y ago
    Another related step from the Chromium developers: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus/discussion https://groups.google.com/a/chromium.org/forum/#!topic/blink...
- silon5 11y ago
  IMO, before http is deprecated, we need public key in DNS support, bypassing the CA system. It would possibly be a lower level of security than CA cert, but would be good for many sites.
  - danudey 11y ago
    That's kind of the issue. There's basically two circumstances where I want to connect with a remote site: 1. I don't care who they are, I just want to read their content (any site I'm not going to log into, e.g. blog posts, etc) 2. I care who they are, I need to know they're them (banks, HN, Twitter, etc.) The current CA system provides the second one, but fundamentally it would be nice if, with the lack of a CA-verified certificate, the server/browser would just encrypt the connection anyway.
Someone1234 11y ago
Someone in the other thread had a genius solution to this: - All domains should now come free with a domain certificate. Seriously, this entire problem set is solved by that one single change. It is one of these ideas that once you hear it you cannot un-hear it. We already know (and as this blog post says) that domain certificates have zero cost associated with creating them, so just bundle it with domain registration and soon competition in that space will force the additional cost to near zero (in particular if it is required). This is a much better solution to "Let's Encrypt" because it scales better, and we don't have all of our eggs in one basket. So who do we lobby to make this happen? PS - Domain registrars won't fight this too hard as their customers will be "forced" to buy a "bundled" domain cert'. I am just hopeful that even if initial prices would be higher, eventually the additional cost will be absorbed into the domain registration itself.
- dragonwriter 11y ago
  > All domains should now come free with a domain certificate. So, every domain registrar should also be a trusted CA?
  - Someone1234 11y ago
    If they meet the requirements other CAs meet, sure, why not? But otherwise they'd have to find a CA to do the signing on their behalf.
  - danudey 11y ago
    It's pretty easy to prove that a given domain was registered by a given registrar, so it's pretty easy to say that e.g. Hover is responsible for example.com, so Hover can request one (!) certificate for .example.com (or re-request it and revoke the old one). Then the only problem is when your registrar is a bad actor, and that's rough because they lose all* their business when people find out that they're screwing over their customers.
- borplk 11y ago
  That's just one of the many pieces of the puzzle. Most people don't understand how certificates work and get themselves in all sorts of trouble, so part of the problem is technical and educational. "Let's Encrypt" is much more than just a certificate authority, in fact other CAs can adopt Let's encrypt protocol (ACME). ACME is arguably solving the bigger part of the problem which is automatic configuration and renewal for the vast majority of people who have no clue how any of this works and don't want to have to think about it.
cleverjake 11y ago
Author appears to not be aware of the upcoming free SSL certificate service from Mozilla, the EFF and more - https://letsencrypt.org/ https://letsencrypt.org/
- dragonwriter 11y ago
  I'd be a lot more willing to consider letsencrypt.org as a valid support for changing the fundamental requirements for communication on the rest of the web when it was a proven service whose practicality (and any pitfalls) for real users in a wide range of cases including those that weren't the most common was well-established, rather than an upcoming one.
- joepie91_ 11y ago
  Did you actually read the article? I've dedicated an entire section of the article to Let's Encrypt.
- datashovel 11y ago
  The author mentions letsencrypt, but their description of why letsencrypt is not a solution makes me think they have a less than complete understanding of modern SSL. Also the configuration issue with regard to not supporting wildcard certs is not a problem IMO. If you're big enough to require multiple subdomains the fact that you're managing multiple certificates instead of one does not need to be a logistical issue. Automation is our friend.
- fieryscribe 11y ago
  Maybe Sven edited the article after the fact, but there is a section on Let's Encrypt
- deleted 11y ago
  [deleted]
- jordanlev 11y ago
  Parent appears to not have actually read the article. FFS, there's a bold heading halfway down: "Let's Encrypt is not a complete solution either"
protomyth 11y ago
So, under this scheme, what is the best practice for dealing with all the web servers in devices such as printers, routers, copiers, embedded systems, etc.? Quite a lot of these have no provision and, in quite a few cases, not the cpu power to do https.
- finnn 11y ago
  most printers/routers/copiers offer HTTPS from what I've seen. Sometimes it's on by default, usually not. They just use self-generated, self-signed certificates. There are problems with that, but CPU power isnt one of them.
  - greglindahl 11y ago
    My experience with large numbers of smart powerstrips is that they support ssh and https, but it's not reliable. Their telnet and http is reliable. I don't know why this is the case, but there you have it.
    - nine_k 11y ago
      Smart powerstrips are still a minority of connected devices. Printers, routers, etc — anything that can afford a $5 ARM or MIPS core — have plenty enough power to allow TLS access. Getting a certificate for each of them to provide a Web interface is another story. In corporate environment the IT department will probably install their own certificates, automatically trusted by corporate browsers. Home-oriented devices will probably use massively-copied certificates instead of unique ones. It's not as secure as a per-device unique certificate, but definitely more secure than no encryption at all.
      - finnn 11y ago
        But it mandates that you click through an SSL warning, which no user should ever have to do unless they are actually testing SSL-related stuff. Otherwise, it's just teaching everyone bad practices.
tptacek 11y ago
This post has an incomplete and somewhat dismissive take on certificate pinning. It's true that pinning involves a degree of trust on the certificate presented on the first connection, and that is a weakness. But that weakness is mitigated. Browsers also rely on the CA signatures for that certificate (pinning augments CAs, but doesn't replace them). The potency of pinning is subtle, because nobody trusts CAs (and shouldn't!). You have to think beyond just your browser, and you have to grok that CAs are a finite resource for your adversaries. You trust the CA-signed pinned cert for an HPKP site on the first connection. But other browsers have had that pin cached, and when the pin is tampered with, they don't trust it. When they see the broken pin, they can do more than just not trust the connection: they can also relay the evidence that a CA is implicated in signing a certificate that breaks a pin. Google won't say so specifically, but it's not unlikely that some of the last few CAs to have been burned by trying to sign Google sites were caught because of pinning. Pinning protects more than individual browsers; it also uses the installed base of pinning browsers to protect everyone, not just those using pinning browsers, by turning them into a global surveillance system for compromised CAs.
ozten 11y ago
Progress is never easy. Firefox will be a forcing function for fixing the most critical issues raised in the blog post.
deleted 11y ago
[deleted]
jkire 11y ago
> I do not believe that there is data that is "not important enough to encrypt". I do believe this. When I visit a static web page over SSL people sniffing my connection are almost always going to have a good idea of which domain I'm looking at (either by IP, or the DNS requests I just fired off, etc.), so the attackers know what content I'm seeing. So why encrypt it? The benefit is that we can trust that static content really did come from that domain and wasn't changed by a MitM, but this can be solved by simply including a signature of the content rather than encrypting everything. SSL is really not cheap CPU wise; it can limit the usefulness of a small, personal, cheap VPS for hosting even moderately popular content. Signing static content is essentially free, since we can pre-compute them. If the writer really does believe everything should be encrypted (this necessarily includes metadata), then I assume he would advocate Mozilla deprecate supporting for non-Tor connections? :)
- azurezyq 11y ago
  SSL has became significantly efficient on newer CPU w/ hardware supports. And even the static page itself may be not worth to steal, there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. Moreover, MitM can easily insert ads in the page without a SSL connection. I've ever interviewed some guy from a ISP contractor (not US), their business is to mine search queries from user URLs and inject targeted ads into static pages sent to user.
  - jkire 11y ago
    > ...there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. And SSL should be used in those cases. I'm not saying you should never use SSL, I just don't buy the idea that you need to encrypt everything. Due to all the unencrypted bits like the IP address and DNS (and SNI?), sniffers can already guess what domains you're visiting anyway. Encrypting in those gives nothing that signing the plain text wouldn't. > ...MitM can easily insert ads in the page without a SSL connection Not if the response is also signed. (Assuming clients actually checked the signatures of course)
- joepie91_ 11y ago

46 points by joepie91_ 11y ago

There's one solution that the author didn't cover: Start treating self-signed certs as unencrypted. Then, deprecate http support over a multi-year phase out. That way, website owners who want to keep their status quo, can just add a self signed cert and their users will be none the wiser. For https there are two major objectives. 1) Prevent MITM attacks. 2) Prevent snooping from passive monitoring. Self-signed certs can prevent #2, which the IETF has adopted as a Best Current Practice (https://tools.ietf.org/html/rfc7258 https://tools.ietf.org/html/rfc7258). I'm much more in favor of trying to at least do one of the two objectives of https, rather than refusing to do anything until we are able to do both objectives. Here's a proposed way of phasing this plan in over time: 1. Mid-2015: Start treating self signed certificates as unencrypted connections (i.e. stop showing a warning, but the UI would just show the globe icon, not the lock icon). This would allow website owners to choose to block passive surveillance without causing any cost to them or any problems for their users. 2. Late-2015: Switch the globe icon for http sites to a gray unlocked lock. The self signed certs would still be the globe icon. The would incentivize website owners to at least start blocking passive surveillance if they want to keep the same user experience as previous. Also, this new icon wouldn't be loud or intrusive to the user. 3. Late-2016: Change the unlocked icon for http sites to a yellow icon. Hopefully, by the end of 2016, Let's Encrypt has taken off and has a lot of frameworks like wordpress including tutorials on how to use it. This increased uptake of free authenticated https, plus the ability to still use self-signed certs for unauthenticated https (remember, this still blocks passive adversaries), would allow website owners enough alternative options to start switching to https. The yellow icon would push most over the edge. 4. Late-2017: Switch the unlocked icon for http to red. After a year of yellow, most websites should already have switched to https (authenticated or self-signed), so now it's time to drive the nail in the coffin and kill http on any production site with a red icon. 5. Late-2018: Show a warning for http sites. This experience would be similar to the self-signed cert experience now, where users have to manually choose to continue. Developers building websites would still be able to choose to continue to load their dev sites, but no production website would in their right mind choose to use http only. Here's two relevant Bugzilla bugs: Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 https://bugzilla.mozilla.org/show_bug.cgi?id=431386 Switch generic icon to negative feedback for non-https sites: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 https://bugzilla.mozilla.org/show_bug.cgi?id=1041087

ajanuary 11y ago
Won't treating self-signed certificates as not-errors make 1 (prevent MITM attacks) worse though? You could then MITM an https site, serve up a self-signed cert, and anyone but the most observant users won't notice that something that used to be secure https now isn't. It isn't about refusing to do anything but both at once, it's that doing only one of them makes the other worse.
- api 11y ago
  No, the idea would be that http becomes https with a self-signed cert. It shows as 'not protected' the way http does now to the user. It only turns green or gets the key box when it's a signed cert.
  - ajanuary 11y ago
    Very few people are going to notice that something that used to be green now isn't. In an attempt to increase security against passive monitoring (a laudable aim) this scheme heavily neuters https' ability to increase security against MITM attacks.
    - oconnore 11y ago
      You are describing a downgrade attack, which is addressed by HSTS, not TLS.
      - ajanuary 11y ago
        HSTS is designed to protect against downgrading from HTTPS to HTTP. Best I can tell, it doesn't protect against downgrading from an HTTPS with a validated certificate chain to HTTPS without a validated certificate chain. To do that, you would need something like certificate pinning. Once there is a widely deployed mechanism for detecting when a certificate has erroneously changed it would be more feasible to stop treating self-signed certificates as errors.

simonhamp 11y ago

"problems that absolutely need solving _before_ a forced global deployment of TLS can happen" I'm all for this switch to SSL. But there's no way Mozilla's announcement will effect global deployment of TLS... not with 11.7% market share (NetMarketShare.com, https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0 https://www.netmarketshare.com/browser-market-share.aspx?qpr...). The realist in me says this will just frustrate developers as staunch advocates of Firefox pester for working services while higher-ups refuse to justify the cost to suit a possible minority userbase. These users being forced to either switch browser or move service provider.

kazazes 11y ago
Chromium/Chrome have already proposed a step in the same direction, pushing your market share figure up to 37.4%. [1] [1] https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure https://www.chromium.org/Home/chromium-security/marking-http...
- mbrubeck 11y ago
  Another related step from the Chromium developers: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus/discussion https://groups.google.com/a/chromium.org/forum/#!topic/blink...
silon5 11y ago
IMO, before http is deprecated, we need public key in DNS support, bypassing the CA system. It would possibly be a lower level of security than CA cert, but would be good for many sites.
- danudey 11y ago
  That's kind of the issue. There's basically two circumstances where I want to connect with a remote site: 1. I don't care who they are, I just want to read their content (any site I'm not going to log into, e.g. blog posts, etc) 2. I care who they are, I need to know they're them (banks, HN, Twitter, etc.) The current CA system provides the second one, but fundamentally it would be nice if, with the lack of a CA-verified certificate, the server/browser would just encrypt the connection anyway.

Someone1234 11y ago

Someone in the other thread had a genius solution to this: - All domains should now come free with a domain certificate. Seriously, this entire problem set is solved by that one single change. It is one of these ideas that once you hear it you cannot un-hear it. We already know (and as this blog post says) that domain certificates have zero cost associated with creating them, so just bundle it with domain registration and soon competition in that space will force the additional cost to near zero (in particular if it is required). This is a much better solution to "Let's Encrypt" because it scales better, and we don't have all of our eggs in one basket. So who do we lobby to make this happen? PS - Domain registrars won't fight this too hard as their customers will be "forced" to buy a "bundled" domain cert'. I am just hopeful that even if initial prices would be higher, eventually the additional cost will be absorbed into the domain registration itself.

dragonwriter 11y ago
> All domains should now come free with a domain certificate. So, every domain registrar should also be a trusted CA?
- Someone1234 11y ago
  If they meet the requirements other CAs meet, sure, why not? But otherwise they'd have to find a CA to do the signing on their behalf.
- danudey 11y ago
  It's pretty easy to prove that a given domain was registered by a given registrar, so it's pretty easy to say that e.g. Hover is responsible for example.com, so Hover can request one (!) certificate for .example.com (or re-request it and revoke the old one). Then the only problem is when your registrar is a bad actor, and that's rough because they lose all* their business when people find out that they're screwing over their customers.
borplk 11y ago
That's just one of the many pieces of the puzzle. Most people don't understand how certificates work and get themselves in all sorts of trouble, so part of the problem is technical and educational. "Let's Encrypt" is much more than just a certificate authority, in fact other CAs can adopt Let's encrypt protocol (ACME). ACME is arguably solving the bigger part of the problem which is automatic configuration and renewal for the vast majority of people who have no clue how any of this works and don't want to have to think about it.

cleverjake 11y ago

Author appears to not be aware of the upcoming free SSL certificate service from Mozilla, the EFF and more - https://letsencrypt.org/ https://letsencrypt.org/

dragonwriter 11y ago
I'd be a lot more willing to consider letsencrypt.org as a valid support for changing the fundamental requirements for communication on the rest of the web when it was a proven service whose practicality (and any pitfalls) for real users in a wide range of cases including those that weren't the most common was well-established, rather than an upcoming one.
joepie91_ 11y ago
Did you actually read the article? I've dedicated an entire section of the article to Let's Encrypt.
datashovel 11y ago
The author mentions letsencrypt, but their description of why letsencrypt is not a solution makes me think they have a less than complete understanding of modern SSL. Also the configuration issue with regard to not supporting wildcard certs is not a problem IMO. If you're big enough to require multiple subdomains the fact that you're managing multiple certificates instead of one does not need to be a logistical issue. Automation is our friend.
fieryscribe 11y ago
Maybe Sven edited the article after the fact, but there is a section on Let's Encrypt
deleted 11y ago
[deleted]
jordanlev 11y ago
Parent appears to not have actually read the article. FFS, there's a bold heading halfway down: "Let's Encrypt is not a complete solution either"

protomyth 11y ago

So, under this scheme, what is the best practice for dealing with all the web servers in devices such as printers, routers, copiers, embedded systems, etc.? Quite a lot of these have no provision and, in quite a few cases, not the cpu power to do https.

finnn 11y ago
most printers/routers/copiers offer HTTPS from what I've seen. Sometimes it's on by default, usually not. They just use self-generated, self-signed certificates. There are problems with that, but CPU power isnt one of them.
- greglindahl 11y ago
  My experience with large numbers of smart powerstrips is that they support ssh and https, but it's not reliable. Their telnet and http is reliable. I don't know why this is the case, but there you have it.
  - nine_k 11y ago
    Smart powerstrips are still a minority of connected devices. Printers, routers, etc — anything that can afford a $5 ARM or MIPS core — have plenty enough power to allow TLS access. Getting a certificate for each of them to provide a Web interface is another story. In corporate environment the IT department will probably install their own certificates, automatically trusted by corporate browsers. Home-oriented devices will probably use massively-copied certificates instead of unique ones. It's not as secure as a per-device unique certificate, but definitely more secure than no encryption at all.
    - finnn 11y ago
      But it mandates that you click through an SSL warning, which no user should ever have to do unless they are actually testing SSL-related stuff. Otherwise, it's just teaching everyone bad practices.

tptacek 11y ago

This post has an incomplete and somewhat dismissive take on certificate pinning. It's true that pinning involves a degree of trust on the certificate presented on the first connection, and that is a weakness. But that weakness is mitigated. Browsers also rely on the CA signatures for that certificate (pinning augments CAs, but doesn't replace them). The potency of pinning is subtle, because nobody trusts CAs (and shouldn't!). You have to think beyond just your browser, and you have to grok that CAs are a finite resource for your adversaries. You trust the CA-signed pinned cert for an HPKP site on the first connection. But other browsers have had that pin cached, and when the pin is tampered with, they don't trust it. When they see the broken pin, they can do more than just not trust the connection: they can also relay the evidence that a CA is implicated in signing a certificate that breaks a pin. Google won't say so specifically, but it's not unlikely that some of the last few CAs to have been burned by trying to sign Google sites were caught because of pinning. Pinning protects more than individual browsers; it also uses the installed base of pinning browsers to protect everyone, not just those using pinning browsers, by turning them into a global surveillance system for compromised CAs.

ozten 11y ago

Progress is never easy. Firefox will be a forcing function for fixing the most critical issues raised in the blog post.

deleted 11y ago

[deleted]

jkire 11y ago

> I do not believe that there is data that is "not important enough to encrypt". I do believe this. When I visit a static web page over SSL people sniffing my connection are almost always going to have a good idea of which domain I'm looking at (either by IP, or the DNS requests I just fired off, etc.), so the attackers know what content I'm seeing. So why encrypt it? The benefit is that we can trust that static content really did come from that domain and wasn't changed by a MitM, but this can be solved by simply including a signature of the content rather than encrypting everything. SSL is really not cheap CPU wise; it can limit the usefulness of a small, personal, cheap VPS for hosting even moderately popular content. Signing static content is essentially free, since we can pre-compute them. If the writer really does believe everything should be encrypted (this necessarily includes metadata), then I assume he would advocate Mozilla deprecate supporting for non-Tor connections? :)

azurezyq 11y ago
SSL has became significantly efficient on newer CPU w/ hardware supports. And even the static page itself may be not worth to steal, there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. Moreover, MitM can easily insert ads in the page without a SSL connection. I've ever interviewed some guy from a ISP contractor (not US), their business is to mine search queries from user URLs and inject targeted ads into static pages sent to user.
- jkire 11y ago
  > ...there may be other things valuable for sniffering such as your identity (e.g., cookie) or your browsing habits. And SSL should be used in those cases. I'm not saying you should never use SSL, I just don't buy the idea that you need to encrypt everything. Due to all the unencrypted bits like the IP address and DNS (and SNI?), sniffers can already guess what domains you're visiting anyway. Encrypting in those gives nothing that signing the plain text wouldn't. > ...MitM can easily insert ads in the page without a SSL connection Not if the response is also signed. (Assuming clients actually checked the signatures of course)
joepie91_ 11y ago