Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
3 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

There are a few points that your approach hasn't considered:

  • encrypt parts of the URI or all of it

    How will you encrypt the URI? The browser does it or the web-page? If the browser does it, how does the browser know what part of the URI to encrypt and if the web-page does it, how will you get the TLS certificate of the server? Read thisRead this. Also, you can't encrypt the entire URL otherwise the browser will not know the server that it should talk to.

  • There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

    If you are using TLS, then the replay detection is already handled by TLS (Are SSL encrypted requests vulnerable to Replay Attacks?).

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 11, 22 and some other google search results: It's a bad idea, how to do it in Java

There are a few points that your approach hasn't considered:

  • encrypt parts of the URI or all of it

    How will you encrypt the URI? The browser does it or the web-page? If the browser does it, how does the browser know what part of the URI to encrypt and if the web-page does it, how will you get the TLS certificate of the server? Read this. Also, you can't encrypt the entire URL otherwise the browser will not know the server that it should talk to.

  • There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

    If you are using TLS, then the replay detection is already handled by TLS (Are SSL encrypted requests vulnerable to Replay Attacks?).

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 1, 2 and some other google search results: It's a bad idea, how to do it in Java

There are a few points that your approach hasn't considered:

  • encrypt parts of the URI or all of it

    How will you encrypt the URI? The browser does it or the web-page? If the browser does it, how does the browser know what part of the URI to encrypt and if the web-page does it, how will you get the TLS certificate of the server? Read this. Also, you can't encrypt the entire URL otherwise the browser will not know the server that it should talk to.

  • There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

    If you are using TLS, then the replay detection is already handled by TLS (Are SSL encrypted requests vulnerable to Replay Attacks?).

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 1, 2 and some other google search results: It's a bad idea, how to do it in Java

2 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

There are a few points that your approach hasn't considered:

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 1, 2 and some other google search results: It's a bad idea, how to do it in Java

There are a few points that your approach hasn't considered:

  • encrypt parts of the URI or all of it

    How will you encrypt the URI? The browser does it or the web-page? If the browser does it, how does the browser know what part of the URI to encrypt and if the web-page does it, how will you get the TLS certificate of the server? Read this. Also, you can't encrypt the entire URL otherwise the browser will not know the server that it should talk to.

  • There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

    If you are using TLS, then the replay detection is already handled by TLS (http://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks).

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 1, 2 and some other google search results: It's a bad idea, how to do it in Java

There are a few points that your approach hasn't considered:

  • encrypt parts of the URI or all of it

    How will you encrypt the URI? The browser does it or the web-page? If the browser does it, how does the browser know what part of the URI to encrypt and if the web-page does it, how will you get the TLS certificate of the server? Read this. Also, you can't encrypt the entire URL otherwise the browser will not know the server that it should talk to.

  • There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

    If you are using TLS, then the replay detection is already handled by TLS (Are SSL encrypted requests vulnerable to Replay Attacks?).

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 1, 2 and some other google search results: It's a bad idea, how to do it in Java

    Mod Moved Comments To Chat
1
source | link

There are a few points that your approach hasn't considered:

  • encrypt parts of the URI or all of it

    How will you encrypt the URI? The browser does it or the web-page? If the browser does it, how does the browser know what part of the URI to encrypt and if the web-page does it, how will you get the TLS certificate of the server? Read this. Also, you can't encrypt the entire URL otherwise the browser will not know the server that it should talk to.

  • There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

    If you are using TLS, then the replay detection is already handled by TLS (http://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks).

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 1, 2 and some other google search results: It's a bad idea, how to do it in Java