Since you're doing a 301 redirect over HTTP, someone could man-in-the-middle that connection and redirect you anywhere they wanted - in particular they could actually not redirect you at all, and instead get between your computer and https://login.example.com
, monitoring your connection and serving you its contents under the name http://login.example.com
instead.
A way to mitigate this is to use an HSTS HTTP header - when the user first loads your page, it tells their browser that your site is to be loaded on HTTPS only until some date in the future (the directive typically has an expiration date set in the far future). This means that once the user connects to your site once via HTTPS, they will always do so in the future until the expiration of the HSTS directive.
This leaves one last scenario - say that the attacker MITMs the connection BEFORE the user's browser ever sees the HSTS header from your server. In that case the user's browser never knows that it shouldn't use non-HTTPS connections. A way to mitigate this is to include your website in the HSTS preload list, which means that web browsers ship already knowing that your site is HTTPS-only. Chrome, Firefox, Safari, IE11, and Edge all have an HSTS preload list that includes the Chrome HSTS Preload List, and in a few steps you can submit your site too - more information on the Chrome HSTS Preload List.
If you put your site on the HSTS preload list and complete what that entails, then you can have reasonable assurance that anybody using new versions of those browsers won't be vulnerable to an HTTPS-to-HTTP MITM downgrade attack by a casual attacker.
Just keep in mind that once your site is on the HSTS preload list, it's not very quick to get it back out of everybody's browsers, since any browser that hasn't been upgraded (again) will expect your site to be loaded via HTTPS only.