What you’re doing at the moment is okay, but there are far far better ways to do it.
The problem of man in the middle attacks here is that to insert yourself between wordpress.org and a server at a data centre is no easy task, so this scenario is very unlikely.
However
If you abandon the built in updater and instead rely on git repositories to pull down your data, then you can guarantee 100% that your plugins and themes are secure, even if a man in the middle attack occurs.
This is because of the reliability promises git makes. A git repository has an SHA-1 hash which represents its VCS history, and any attempt to ‘meddle’ or manipulate a git repository to add code will invalidate that hash, causing git to balk. Because of this, so long as that hash is good, you can pull code changes down from anywhere, no matter how untrustworthy thanks to the cryptographic guarantee.
Here’s Linus Torvalds talking about trust and reliability in Git far better than I could explain:
http://youtu.be/4XpnKHJAok8?t=56m10s
Once you’ve moved to a version controlled setup, you can set your wp-content folder etc to read only for the servers Apache/WWW/Nginx user. Should a non-git repository be corrupted or compromised, you can simply re-checkout the repository in place and undo the damage.
Provisioning/deployment tools such as Composer would also be useful here.
Note that while Git would prevent a man in the middle attack by highlighting the data inconsistencies and providing evidence of tampering, it will only guarantee you have the correct copy of the source. It doesn’t prevent the original developer from having a nervous breakdown and putting a DROP ALL TABLES command in their plugin. For that we have testing in sandboxes, proofreading/code reviews, and support forums.