Why does browser send TLS session ID first time visit a website? - ssl

I read this answer of SSL session tickets vs session ids.
When the server sends the “Server Hello” message, it can include a session identifier. The client should store it and present it in the “Client Hello” message of the next session.
So my guess is that if I visit a website that I never visit before, there will be no Session ID in the Client Hello message.
But when I visit a new website that I randomly choose from Google (I am pretty sure that I never visit that website before) , I see a Session ID is sent in the Client Hello message. Why?

Related

How to check HTTP status code in Apache configuration

Is it possible to check Http status code in Apache configuration as %{REQUEST_STATUS} for instance?
There is no such thing as a "request status", and no way for a server to interact with a browser in the middle of serving an error message.
HTTP is not an interactive protocol; the browser sends a request, the server sends a response, and that's it. So if the browser sends a request, and the application crashes, the server can send a response with 500 and the error details, or a response with 401 requesting the user to log in. Either way, that's the end of the conversation.
When it receives a 401 response, the browser can't say "here's the login details, carry on with the current request", it has to make a new request. It can make an identical request, which might reproduce the error message; but the original error message is gone.
If the requirement is to show a different amount of detail to different users, you need some notion of optional authentication, so that the server can decide immediately whether to include the error details or not, without an extra round-trip to the browser. I would suggest either:
Have a list of IP addresses which the application can check against; if the IP address of the request is in the list, include the error details.
Have a custom login system where you can authenticate and set a "session cookie" in the browser. If the user has an active session cookie, include the error details.

Password-less website authentification / login

Many websites have a password-less authentification system, i.e. you can signup / login / logout only with an email, and no password is ever required.
How would one implement such a system? (framework and language-agnostic)
Note: I've already read:
The definitive guide to form-based website authentication,
Password-less authentication in web apps - How safe it is?
and a few other security.SE posts
and searched for SO posts about how to actually implement a [password-less] login system, but without much success ; I haven't found a canonical question on SO about implementation of a password-less auth
Manually logging in a user without password is linked but not the same thing: there the idea is login immediately after a successful account creation, but not necessarily a 100% password-less authentification system.
As I searched for a long time for this, here is a summary that I post with SO's "Answer your own question - Q&A-style" feature. I'll update it as often as I can to improve it.
Password-less authentification method #1: "Click on the link in the email we just sent you to login"
Sign-up:
client fills signup form
client AJAX POST http://example.com/_signup {email: 'test#test.com', data: 'data'}
server checks if user already exists
client message: "Success: an email has been sent" or "Fail: already exists"
server creates DB record for user
server generates a random session ID + sends email with link: http://example.com/?sessid=f65a5bc45
Log-in:
client fills login form
client AJAX POST http://example.com/_login {email: 'test#test.com'}
client message: "An email has been sent if the account exists"
server checks if the email is in the database
server generates a random session ID + sends email with link: http://example.com/?sessid=f65a5bc45
Open link:
client opens the link http://example.com/?sessid=f65a5bc45
client: document.cookie = "sessid=f65a5bc45; expires=Fri, 31 Dec 9999 23:59:59 GMT" (or do this server side, e.g. with PHP)
client: ?sessid query string removed, navigate to /
Open /:
client: AJAX POST example.com/_load {sessid: getCookieValue('sessid')}
server checks if valid sessid. if so, sends user data to client
client xhr.onreadystatechange: fills page with user data
Password-less authentification method #2: "Enter the code in the email we just sent you to login, e.g. 123 456"
Sign-up:
client fills signup form
client AJAX POST http://example.com/_signup {email: 'test#test.com', data: 'data'}
client message "An email has been sent, please enter your code here:" or "Fail: already exists"
server creates DB record for user
idem next paragraph starting at (*)
Log-in:
client fills login form
client AJAX POST http://example.com/_login {email: 'test#test.com'}
client message "An email has been sent if the account exists, please enter your code here:"
server checks if email in database
(*) server generates random number + sends email: "Here is your code: 123 456"
client fills code form
client AJAX POST http://example.com/_login {email: 'test#test.com', code: '123456'}
server checks if valid code. if so, server generates a random session ID, and sends to client
client: document.cookie = "sessid=f65a5bc45; expires=Fri, 31 Dec 9999 23:59:59 GMT" (or do this server side with PHP)
client: navigate to /
Open /:
client AJAX POST http://example.com/_load {sessid: getCookieValue('sessid')}
server checks if valid sessid. if so, sends user data to client
client xhr.onreadystatechange: fills page with user data

Couldn’t get GCM token because of banned servers

I have this problem for so long but I figured out that in my country some of the servers has been banned by the country and I guess that expo’s servers are one of them.
I’m getting this error only when the user doesn’t use proxy and every time the users use proxy they can get push token with no problem.
Is there any solution for that?Why does getting push token by expo needs to connect to server?
Is there any other way to get user’s token of theirs devises?

X-CSRF-Token issue in ionic. Every time a different token is received

I have a backend with Drupal.
Using Drupal Services to interact with. Which provides a rest server.
Created endpoint named 'api'.
Following sequence works in normal browser or any http client like postman :-
example.com/api/login (works).
api sends back user data (token,session id, session name etc).
Further any request I make, I send token as X-CSRF-Token (all requests work).
I can even logout the same session with the token received before.
IN IONIC APP :-
I can login and I also store user data (token, session data etc.) in local storage after login.
Here's the difference in app :-
When I send the same token back to server while making a request (say logout).
Server's response is "User is not Logged In."
Why does this happen?
Update :-
After logging in I tried getting the current token from the server, and it was different from the one I saved after successfully logging in.
Every time a different token is received.
I faced the same issue. Problem was i never set the cookie and chrome did this for me automatically.
Luckily i found this great site:
drupalionic.org
There are links to a view demos as well as good descriptions and code.
So what you have to do is:
- log in
- retrieve session data and set cookie
- perform subsequent requests with the cookie data and X-CSRF-Token in your header
Here is a flowchart:
Was this helpful for you?

JMETER-certificate is not trusted message while login the facebook account

When I was working on facebook.com to recorded the login process using jmeter, then I came across the following error message. what should we do in such condition in order to surpass this step and directly gets login into the facebook application using the proxy server setting for the recording purpose.
The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issue)
As per Recording HTTPS Traffic with JMeter's Proxy Server I believe that it'll be quite enough to clear your browser history.