Impossible d'obtenir une ressource avec openssl s

J'ai essayé de suivre la commande openssl s_client -connect google.com:443et je pouvais me connecter avec google.com via SSL.

Mais quand j'ai essayé d'obtenir des ressources en utilisant, GET /?q=cats HTTP/1.1 <enter> Host google.com <enter><enter>j'ai reçu le message ci-dessous:

HTTP/1.1 400 Bad Request
Date: Wed, 19 Aug 2015 21:12:02 GMT
Server: Apache
Content-Length: 307
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Request header field is missing ':' separator.<br />
<pre>
Host google.com</pre>
</p>
</body></html>
closed

Si je ne spécifie pas de version HTTP et que GET /?q=cats <enter>je l’ utilise, j’obtiens une réponse en dessous. Dans la réponse, je peux voir l'URL correcte https://www.google.co.in/?q=cats&gws_rd=cr&ei=yPPUVYeVApGzuATIkpuQCwet si j'utilise le même navigateur, cela fonctionne.

Est-ce qu'il me manque des en-têtes ou autre chose?

HTTP/1.0 302 Found
Location: https://www.google.co.in/?q=cats&gws_rd=cr&ei=yPPUVYeVApGzuATIkpuQCw
Cache-Control: private
Content-Type: text/html; charset=UTF-8
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Date: Wed, 19 Aug 2015 21:23:20 GMT
Server: gws
Content-Length: 273
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: PREF=ID=1111111111111111:FF=0:TM=1440019400:LM=1440019400:V=1:S=fdzyHaeMMBcBYPPy; expires=Fri, 18-Aug-2017 21:23:20 GMT; path=/; domain=.google.com
Set-Cookie: NID=70=Xxap0a_fYjPIwnvwUuyUqKaT6UH6ZjttA6zv6CYv8qVGMCuOEyNRc8hR2JCi1X_8522QMF2OpsG9dDrWphQh-df0orBmG-DC0WCTF9A_YVJYp3YSgQyap5GlL11EBjff; expires=Thu, 18-
Feb-2016 21:23:20 GMT; path=/; domain=.google.com; HttpOnly
Alternate-Protocol: 443:quic,p=1
Alt-Svc: quic=":443"; p="1"; ma=604800

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="https://www.google.co.in/?q=cats&amp;gws_rd=cr&amp;ei=yPPUVYeVApGzuATIkpuQCw">here</A>.
</BODY></HTML>
read:errno=0

Un autre type de réponse 302.

**GET / HTTP/1.1
Host: www.google.com**

HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: https://www.google.co.in/?gfe_rd=cr&ei=7_3UVfDeCuPI8AeMkZzwDQ
Content-Length: 262
Date: Wed, 19 Aug 2015 22:06:39 GMT
Server: GFE/2.0
Alternate-Protocol: 443:quic,p=1
Alt-Svc: quic=":443"; p="1"; ma=604800

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="https://www.google.co.in/?gfe_rd=cr&amp;ei=7_3UVfDeCuPI8AeMkZzwDQ">here</A>.
</BODY></HTML>

http openssl

— hagrawal
source

Pourquoi pensez-vous que cela est lié à infosec? Pour moi, il semble que le problème soit lié à l'API et non à votre utilisation de SSL.

— Neil Smithline

@NeilSmithline Alors quel site SO pensez-vous avoir raison de poser cette question? C’est ici que les gens en sauront plus sur la communication SSL et sur tous ...

Je demandais simplement pourquoi vous pensez que cela est lié à la sécurité. On dirait que vous pensez que SSL est le problème. Je demandais juste pourquoi.

— Neil Smithline

D'accord. Le problème n'est pas SSL mais lié à la communication SSL.

Quand Google dit

Request header field is missing ':' separator.

Ce qu'ils veulent dire en réalité, c'est que le champ d'en-tête de la demande doit utiliser un séparateur ':'.

Donc au lieu d'envoyer ceci:

GET /?q=cats HTTP/1.1<enter> 
Host google.com<enter>
<enter>

Vous devez envoyer ceci:

GET /?q=cats HTTP/1.1<enter> 
Host: google.com<enter>
<enter>

(Notez le: séparant "hôte" et "google.com")

Une fois que cela est fait, vous obtenez un 302:

HTTP/1.0 302 Found
Location: https://www.google.co.in/?q=cats&gws_rd=cr&ei=yPPUVYeVApGzuATIkpuQCw

Je reçois en fait un 301 sur la même demande:

HTTP/1.1 301 Moved Permanently
Location: https://www.google.com/?q=cats

Ce ne sont pas des réponses d'erreur, ce sont des réponses de redirection. Google a entendu notre demande et souhaiterait que nous le demandions différemment. Dans mon cas, il m'a dit que je ne devrais pas demander "google.com", je devrais demander "www.google.com", et je devrais garder cela à l'esprit pour la prochaine fois. Dans votre cas, il souhaitait que vous accédiez à www.google.co.in et que vous utilisiez une chaîne de requête différente - vous êtes probablement en Inde et souhaitaient que vous utilisiez une version locale de Google. En ce qui concerne le fait que vous souhaitiez utiliser une chaîne de requête différente, ce sont des paramètres normaux de chaîne de requête Google (gws_rd, ei); ils ne font que nourrir votre requête pour vous.

C'est le comportement normal d'une application Web. Vous avez rédigé une requête à la main. La Web App (Google) n'a pas aimé certains aspects de votre requête et l'a réécrite pour qu'elle soit plus conforme à ce qui se serait passé si vous aviez utilisé un navigateur classique et recherché des "chats". Ils ont ensuite remis cette nouvelle URL à votre client (openssl dans ce cas) et lui ont dit d'aller demander à nouveau. Mais puisque vous le faites à la main, vous n'avez plus posé la question et vous l'avez mal interprétée comme une condition d'erreur.

Si je fais ce qu'ils demandent et répète ma requête mais avec Host: www.google.comau lieu de Host: google.com, j'obtiens les résultats escomptés si vous cherchiez des chats.

— Gowenfawr
source

Bonne prise, merci. Mais ça ne marche toujours pas. Je reçois une erreur 302, semblable à celle que j'ai posée dans la dernière partie de ma question.

— hagrawal

@hagrawal, mis à jour pour répondre - en gros, 302 n'est pas une erreur, c'est un indice utile de l'application.

— Gowenfawr

Merci mon pote. Cependant, j'ai pu obtenir la réponse avec Host: google.co.in, pas besoin de www, car je pense que si le nom de domaine est résolu, OpenSL présume qu'il s'agirait d'une requête World Wide Web.

— hagrawal

@hagrawal: Non, OpenSSL n'a rien avec les "demandes du World Wide Web", et le Web ne se soucie pas de savoir si un domaine a wwwou non.

— Grawity

Impossible d'obtenir une ressource avec openssl s_client